gmane.comp.compilers.llvm.devel

MinGW - LLVM Pass - Undefined Reference

Feng Xie — 2012-05-17T00:06:55

Hi,

I have installed the latest MinGW (version 4.6.3 i386, not version 3.X) and then compiled the LLVM source files (version 2.9) on Windows platform (using the default configuration). It seems that those binary tools (such as llvm-bcanalyzer, opt, etc.) have been successfully generated, as they even work well with existing bitcode files compiled and linked on Linux platform (Ubuntu 8.04/10.04/10.10 x86_64).

The sample LLVM pass (namely /lib/LLVMHello.so), however, has not been generated. Especially once I compile any LLVM pass, the MinGW linker (version 2.22 i386) reports many errors due to various undefined references. Thus I wonder whether the LLVM framework supports developing LLVM passes with MinGW or not, or if there are some special issues I missed when compiling the LLVM source files.

Many thanks.

Feng

template patterns w/ Tablegen

Villmow, Micah — 2012-05-16T22:47:55

Is there any way to write patterns in Tablegen so that the same pattern can be used for a SDNode, Intrinsic and PatFrag nodes? Having to duplicate everything three times is messy and annoying to maintain.
Maybe template patterns?
Thanks,
Micah
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

clang looking for gold plugin when used with '-emit-llvm'option

Ashok Nalkund — 2012-05-16T21:47:01

Hi All,
   I built the binaries from the 3.1 final tag 
(http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_31/final/ etc) as below:


  I notice that I can compile a program using clang as below:


  If I try to generate the bitcode only, it gives an error:

I then ran it with -v option and it produces:
 n/crd/neo/temp/jit -ferror-limit 19 -fmessage-length 177 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-dia!
 gnostics
 -o /tmp/test-LU0kNI.o -x c test.c
 /local/mnt/workspace/ashoknn/crd/neo/llvmsvn/build/bin/bin/../lib/LLVMgold.so /tmp/test-LU0kNI.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/l!
 ib/x86_6
4-linux-gnu/gcc/x86_64-linux-gnu/4.5/crtend.o /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/../../../../x86_64-linux-gnu/crtn.o

Any clues?

TIA,
Ashok

announce: The C Conference; San Diego, CA; August 28th

Brandon Philips — 2012-05-16T20:20:28

The first C Conference is happening in San Diego, CA on August 28th
2012. It is focused on the C programming language and modern
developments in that ecosystem.  The conference is co-located with
LinuxCon and Linux Plumbers Conference.

  http://www.cconf.org/

The "Reverse CFP" is open now and tickets are available. Let us know
what you want to see at the conference.

  http://www.cconf.org/pfc/

See you there.

Brandon

Generating Machine Loads

2012-05-16T16:30:29

Codegen Experts,

Given a MachineInstr that is a store, is there a general way to generate
a MachineInstr load from the same address, somewhat analogous to how
loadRegFromStackSlot is a general way to generate a MachineInstr load?
I would rather not to have to re-code this for every target we might
use.  I can't find anything immediately obvious in TargetInstrInfo or
other Target headers.

Thanks!

                             -Dave

Re: NVPTX: __iAtomicCAS support ?

Justin Holewinski — 2012-05-16T14:21:05

There are really two issues here.  

First, the error you are seeing is because calls are disabled in the back-end until an outstanding LLVM core patch is committed.  Hopefully, we'll be able to push that in soon.

Second, __iAtomicCAS() is a CUDA-C built-in function; the implementation is provided by a library linked with the LLVM IR before the NVPTX back-end sees it.  You will need to provide your own implementations for such functions.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

NVPTX: __iAtomicCAS support ?

Dmitry N. Mikushin — 2012-05-16T12:44:12

Dear colleagues,

I'm looking if we can replace nvopencc with LLVM NVPTX in our project.
It turns NVPTX won't work with the code nvopencc can handle (please
see the log below). So are atomic intrinsics not supported or am I
doing call in a wrong way?

Thanks,
- Dima.

SOURCE
========

dmikushin< at >hp2:~> cat kernelgen_monitor.ll
; ModuleID = '/opt/kernelgen/include/kernelgen_monitor.cu'
target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64"
target triple = "ptx64-unknown-unknown"

%struct.kernelgen_callback_t = type { i32, i32,
%"struct.kernelgen::kernel_t"*, i32, i32,
%struct.kernelgen_callback_data_t* }
%"struct.kernelgen::kernel_t" = type opaque
%struct.kernelgen_callback_data_t = type opaque

define ptx_kernel void < at >_Z17kernelgen_monitorPi(i32* %callback) nounwind {
entry:
  %callback.addr = alloca i32*, align 8
  store i32* %callback, i32** %callback.addr, align 8
  %0 = load i32** %callback.addr, align 8
  %1 = bitcast i32* %0 to %struct.kernelgen_callback_t*
  %lock = getelementptr inbounds %s

Re: CloneFunctionInto() overwrites alignment attribute

Ralf Karrenberg — 2012-05-16T12:37:10

Short update:

It is possible to get around the problem by the following workaround:

1) create a temporary function declaration tmpF
2) tmpF->setAttributes(targetF->getAttributes)
3) CloneFunctionInto(targetF, sourceF, ...)
4) targetF->copyAttributesFrom(tmpF)
5) delete tmpF

Storing the attributes of the target and calling setAttributes() after 
cloning does not work, apparently setAttributes() silently ignores 
alignments.

Cheers,
Ralf

On 5/15/12 6:18 PM, Ralf Karrenberg wrote:

Re: ATTN: PTX Back-End Users - EOL

Che-Liang Chiou — 2012-05-16T09:37:29

On Tue, May 15, 2012 at 10:11 PM, Justin Holewinski
<justin.holewinski< at >gmail.com> wrote:
Sound good to me!

Regards,
Che-Liang

Re: Scheduler Roadmap

2012-05-15T20:07:54


Yes, absolutely.  There's certainly value there.

                             -Dave

Re: MCJIT

Daniel Dunbar — 2012-05-15T19:33:36

Right, this shouldn't be required. The nativecodegen component is the
one which is supposed to make sure that X86 gets linked in.

 - Daniel

Re: llvm-config Regression fix (Bug 11886)

Keno Fischer — 2012-05-15T19:01:58

Consider me a buildbot for OS X and let me tell you it works great :).
Thank you so very much.

-Keno

On Tue, May 15, 2012 at 2:47 PM, Daniel Dunbar <daniel< at >zuster.org> wrote:

_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: llvm-config Regression fix (Bug 11886)

Daniel Dunbar — 2012-05-15T18:47:24

I put in two slightly different fixes that I believe should cover the problem:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=156837
  http://llvm.org/viewvc/llvm-project?view=rev&revision=156838

Let me know if your experience disagrees. I'll try and get these into
3.1 if Bill lets me after the buildbots give a check mark.

 - Daniel

On Tue, May 15, 2012 at 5:38 AM, Keno Fischer <kenof< at >stanford.edu> wrote:

Re: TableGen pattern for negated operand

Joe Matarazzo — 2012-05-15T17:42:57

Thanks for the reply Ivan.

I ended up writing a MachineFunctionPass to handle it, using the code
for FoldImmediate in the peephole optimizer as a guide.

Just thought I'd reply to archive my solution on the mail list.

Joe

On Fri, May 11, 2012 at 2:55 AM, Ivan Llopard <ivanllopard< at >gmail.com> wrote:

Re: Metadata for Argument, BasicBlock

Dan Gohman — 2012-05-15T17:14:07


communication channel between passes.  This does not appear to be a
better approach than using LLVM's conventional pass communication channels.

Dan

Re: Metadata for Argument, BasicBlock

Ralf Karrenberg — 2012-05-15T16:29:31

So, is there any chance that metadata for basic blocks is considered a 
useful feature?

There is a patch ready and on the commits-list, it compiles, passes all 
tests, has a test case of its own, and (as far as I can tell) does not 
interfere with anything.

Cheers,
Ralf

On 5/7/12 4:21 PM, Ralf Karrenberg wrote:

CloneFunctionInto() overwrites alignment attribute

Ralf Karrenberg — 2012-05-15T16:18:43

Hi everybody,

I am trying to clone a function body into an existing declaration.
That declaration has the same number of parameters but they differ in 
type and alignment.
Fortunately, it does not care about the type.
Unfortunately, CloneFunctionInto() copies the attributes from the old 
function to the new one unconditionally, overwriting the alignment 
attribute.
Also, the Attribute interface does not allow me to change the alignment 
of a parameter afterwards ("Attempt to change alignment!" assertion). 
Removing the attribute and setting it again is also not allowed.

Note that I don't want to exclude the arguments from cloning (not adding 
them to the ValueMap) since the main point of using CloneFunctionInto() 
is that I don't have to manually rewire them.

I think it is generally not a good idea to just blindly copy and 
overwrite all attributes (including function attributes) since it might 
more often be the case that CloneFunctionInto() is used exactly to copy 
some code into a different signature.

ATTN: PTX Back-End Users - EOL

Justin Holewinski — 2012-05-15T14:11:44

Now that the NVPTX back-end has been integrated into ToT and already
surpasses the PTX back-end in terms of functionality, I plan to remove the
PTX back-end from the LLVM tree soon.  The only change that users will need
to be aware of are the address space mapping (please see
lib/Target/NVPTX/NVPTX.h for the new mappings).  The old intrinsics will
remain valid for the new NVPTX back-end.

What I would like to know is if anyone is against removing this back-end.
 The sources will still be available in LLVM history, including the LLVM
3.1 release, but going forward I plan to only maintain the NVPTX sources.

If I do not hear any objections by the end of the week, I will probably
remove it this week-end.

Re: NVPTX: why ret instruction is not translated to exit in kernel function?

Justin Holewinski — 2012-05-15T14:02:56

Either way is valid.  From the PTX spec:

    A return instruction executed in a top-level entry routine will terminate thread execution.


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: llvm-config Regression fix (Bug 11886)

Keno Fischer — 2012-05-15T12:38:16

Ok, I attached it to the bug. For reference, here's what I'm using on unix
as a workaround as long as this is not fixed:
llvm-config --libfiles | xargs -n 1 -I {} sh -c 'test -f {} && echo {}'

On Tue, May 15, 2012 at 1:07 AM, Albert Graef <Dr.Graef< at >t-online.de> wrote:

_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

LLVM Rc3 sources?

Sylvestre Ledru — 2012-05-15T10:14:50

Hello,

Trying to build llvm & clang 3.1 rc3 from official tarballs, I noticed 
that rc1 provides llvm-3.1rc1.tar.gz which is not provided for the rc3.
I am looking here:
http://llvm.org/pre-releases/3.1/

Any special reasons for that ?

Thanks,
Sylvestre