gmane.comp.compilers.llvm.devel

Re: Question about DSA analysis

Gabriel Southern — 2013-05-22T17:15:35

Hi John,

Thanks for the reply.  The project that Jing is working on is for a class
that I'm TAing for and it involves evaluating the effectiveness of the
alias analysis support in LLVM.  We've modified the project so that it
doesn't require looking at -ds-aa or -steens-aa since it sounds like those
aren't available anymore (originally we had included that as a requirement
because of what's in the documentation).

Do you think those passes might be added back in the future?  If not would
it make sense to remove them from the documentation (we saw them listed in
the current documentation so that is why we thought they should work).

Also I'm working on another project with someone that is using DSA.  I had
a couple of questions about DSA based on your response.

1) What happens if we specify running multiple DSA passes, such as: -dsa-td
-dsa-local

2) If we are interested in both intra- and inter-procedural alias analysis
would switching from -dsa-td to -dsa-eq get that for us.

Thanks for your help.

-Gabriel

On Mon, May 20, 2013 at 7:13 AM, John Criswell <criswell< at >illinois.edu>wrote:

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

Re: TLS with MCJIT (an experimental patch)

Kaylor, Andrew — 2013-05-22T16:30:06

To clarify, MCJIT currently has no GOT support whatsoever for ELF with x86-64 and ARM (and probably others).  My experimental patch was meant as an attempt to get TLS working with static relocation model and small code model.  It's the combination of these two that requires memory in the lower 2GB.  MCJIT works with static and large, but the MC code generator has a problem with TLS and large code model.

Obviously we just need to get PIC support in place for MCJIT.

-Andy

-----Original Message-----
From: Rafael Espíndola [mailto:rafael.espindola< at >gmail.com] 
Sent: Wednesday, May 22, 2013 6:42 AM
To: David Chisnall
Cc: Kaylor, Andrew; LLVM Developers Mailing List
Subject: Re: [LLVMdev] TLS with MCJIT (an experimental patch)

On 22 May 2013 09:37, David Chisnall <David.Chisnall< at >cl.cam.ac.uk> wrote:

Well, these relocations are there because of the general dynamic tls model, so they would be present on all code models.

Cheers,
Rafael

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

Linking Debug+Asserts Shared Library libclang.so: final link failed: Bad value

Raghavendra K — 2013-05-22T16:06:58

Hi,

I downloaded latest 3.2 release of llvm and clang.
used configure to generate the make files
options used:
 ../configure --enable-debug-symbols=yes --enable-keep-symbols=yes --enable-pic=yes  --enable-keep-symbols=yes --enable-debug-runtime=yes --enable-optimized=no --enable-targets=x86 --enable-embed-stdcxx=yes --enable-jit=no CXXFLAGS=-fPIC CFLAGS=-fPIC

Now i get this strange error,cannot link, pls help...how to proceed.

llvm[4]: Linking Debug+Asserts Shared Library libclang.so
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: /home1/ragha/llvmsrc/llvm-3.2.src/build/tools/clang/tools/libclang/Debug+Asserts/ARCMigrate.o: relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::data() const< at >< at >GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


regards
ragha

Re: TLS with MCJIT (an experimental patch)

Konstantin Tokarev — 2013-05-22T13:58:31


22.05.2013, 17:55, "David Chisnall" <David.Chisnall< at >cl.cam.ac.uk>:

http://www.unicom.com/pw/reply-to-harmful.html

Re: TLS with MCJIT (an experimental patch)

Rafael Espíndola — 2013-05-22T13:42:15


Well, these relocations are there because of the general dynamic tls
model, so they would be present on all code models.

Cheers,
Rafael

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

Re: TLS with MCJIT (an experimental patch)

David Chisnall — 2013-05-22T13:37:11


That was, indeed, where this discussion started.  Andrew's suggestion was to use the small code model, in the hope that this would fix some things.  The lack of support for these relocations is what is stopping my code from working with MCJIT, and your removal of EH is stopping it working with the legacy JIT.

David

Re: TLS with MCJIT (an experimental patch)

Rafael Espíndola — 2013-05-22T13:28:46

OK. Are we generating generic dynamic code to do so? It will look like

.byte 0x66
leaq x< at >tlsgd(%rip),%rdi    ; R_X86_64_TLSGD to symbol x (MCJIT has to
create a GOT entry)
.word 0x6666
rex64
call __tls get_addr< at >plt      ; R_X86_64_PLT32 to __tls_get_addr (MCJIT
has to create a GOT and a PLT entry)

This should work from any place in memory. I wouldn't be surprised if
these relocations are not implemented yet, but that should be all that
is needed to get tls working.

Cheers,
Rafael

Re: TLS with MCJIT (an experimental patch)

David Chisnall — 2013-05-22T13:19:27


Ooops, forgot to hit reply-all.  Didn't the LLVM lists used to default to reply-to-list behaviour?


The dynamic linker will have allocated the memory because the TLS variable in question is provided by libc.  It is already allocated before the JIT'd code runs.  The JIT'd code just needs to refer to it.  

>>

Re: TLS with MCJIT (an experimental patch)

Rafael Espíndola — 2013-05-22T12:01:49


I was under the impression that, in the small memory model, each .so
had to be small, but because of the use of GOTs and PLTs they could be
anywhere in memory. If we allocate the tls memory in the same
allocator call that allocates space for the text section this would
work, no?


Cheers,
Rafael

Re: TLS with MCJIT (an experimental patch)

David Chisnall — 2013-05-22T10:22:20


I've asked around, and we don't seem to have anything that can do it.  Checking the code for rtld, it explicitly asks for memory at a specific address and keeps track of the regions it has used.  

David

Re: Static linking of execution engine

Mario Schwalbe — 2013-05-22T09:34:20

Hi,

Am 21.05.13 21:57, schrieb Kaylor, Andrew:

I'm including "JIT.h" directly in the main module, which also uses the
engine. See the small test case attached. Even if I bypass the dummy object
and call LLVMLinkInJIT() directly, it still gets optimized out...

ciao,
Mario

/*
 * vim: set tabstop=4 shiftwidth=4 expandtab:
 */
#define DEBUG_TYPE "ExecutionEngineTest"

#include <llvm/ExecutionEngine/Interpreter.h>
#include <llvm/ExecutionEngine/JIT.h>
#include <llvm/Support/TargetSelect.h>
#include <llvm/LLVMContext.h>
#include <llvm/Module.h>

#include <cassert>

using namespace llvm;

int main(void)
{
    InitializeNativeTarget();
#if 1
    LLVMLinkInJIT();
#endif

    EngineBuilder engineBuilder(new Module("foo", getGlobalContext()));
#if 0
    engineBuilder.setEngineKind(EngineKind::Interpreter);
#else
    engineBuilder.setEngineKind(EngineKind::JIT);
#endif

    const OwningPtr<ExecutionEngine> executionEngine(engineBuilder.create());
    assert(executionEngine && "Failed to create execution engine");

    return 0;
}

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

Re: Is it valid to add parameters to a function once it is created

Duncan Sands — 2013-05-22T08:03:28

Hi Frank,

On 21/05/13 21:19, Frank Winter wrote:

no.  The arguments have to match the function type.  If you had declared
funcType like this "void ()(i32, i32)" then the call to llvm::Function::Create
would have created a function with two arguments, i.e. the arguments are already
there.  However by declaring it "void ()(void)" then it is created with no
arguments and has to stay that way.  Maybe you should declare the type to be
varargs instead (the second parameter to FunctionType::get)?

Ciao, Duncan.

PS: If you build LLVM with assertions enabled and run the verifier on your
generated bitcode, you should find that your bitcode is rejected.

Re: How to find the first block of each loop

Eric Lu — 2013-05-22T05:47:21

Sorry, it is my fault to cause the problem, I will take back the mail.
FWIW, I like to shared some experiences on this problem.
What to do:
 I want to insert a control-block before every outermost loop. My current
solution is: 1) find each outermost loop in some function; 2) find the loop
header with Loop->getHeader() APIs, and then insert the controller block
before the header block of current loop.


In the  first, I don't know we can get the outermost loop list from
LoopInfo, so, I iterate over the BB of function and usr LI->getLoopFor(BB),
to get the Loop object CurLoop, then to do something else...., And I made a
mistake in this process.

Now, I find we can get Loop object from LoopInfo like the follow example
LoopInfo::iterator LIB = LI->begin;

*LIB points to the outer most loop of the function.  It is done now.

Sorry for bothering all of you!


Eric Lu




On Tue, May 21, 2013 at 3:41 PM, Eric Lu <eirc.lew< at >gmail.com> wrote:

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

Custom delay slot insertion

Vikram Singh — 2013-05-22T03:58:46

hi 

I am porting llvm 3.1 for a custom processor. I'm taking reference from
sparc architecture. The problem I'm facing that sparc has 1 delay slot in
call and conditional instructions. In my case some have 1 and some have 2
delay slots. But the backend is inserting only 1 delay slot instruction. I
do not know how to insert more than 1 instruction in the delay slots. 
Please suggest some solution. 

vikram



--
View this message in context: http://llvm.1065342.n5.nabble.com/Custom-delay-slot-insertion-tp57898.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.

Header Maps?

Rick Mann — 2013-05-22T03:51:01

I'm battling with Xcode and Boost, so I apologize with the somewhat Xcode-specific parts of my question.

I know Xcode generates Header Maps, and I've looked at clong::HeaderMap. But I don't really know how Xcode chooses to create Header Maps.

I'm trying to avoid adding a search path for all of Boost, and only including the Boost headers that actually get used. Xcode seems to inconsistently find headers. One problem is that boost inconsistently uses quotes-vs.-angle brackets when including.

Anyway, is there a tool that can dump out a .hmap file in human-readable form, to help me see what Xcode is doing?

BTW, I've tried asking on the Xcode list for insight into how Xcode tries to use .hmaps, but have yet to receive a good answer.

Thanks!

Best strategy to add a parameter to a function

Frank Winter — 2013-05-22T00:27:29

I am trying to build a function (C++ Builder) and at the same time 
extend its parameter set. Here's what I try to do:

Value* arg0 = add_param_float("arg0");
Value* tmp = builder->CreateFAdd(arg0,some_previous_value);
Value* arg1 = add_param_float("arg1");

The function add_param_float should add a 'float' parameter to the 
function and return its value. Right now it's implemented like this

Value* add_param_float() {
     return new llvm::Argument( 
llvm::Type::getFloatTy(llvm::getGlobalContext()) , param_next() , 
mainFunc );
}

where param_next just figures some new, unused name for the argument and 
mainFunc is the function being built.

This works to a certain extent. I am seeing issues with certain type 
printers and I assume the way the argument is added to the function is 
not a strictly valid thing to do.
I guess one cannot change the function type once it's created. (Then 
maybe the constructor of Argument should not be public).

However, in my setup I need to add new arguments to the function. What 
would be the best way to do it?

I was thinking of implementing a new function like CloneFunction which 
takes an additional argument that can be added to it. But, is this 
really necessary? Isn't there a simpler, more straight-forward way to do 
this?

Any help/thoughts is appreciated!
Frank

Re: Inlining sqrt library function in X86

Gurd, Preston — 2013-05-21T22:10:38

Thanks, Ben.

If I do not use the -ffast-math, then the generated code calls "sqrt". If I do use -ffast-math, then the code calls __sqrt_finite.

The use of -ffast-math seems to result in gcc's math.h including /usr/include/x86_64-linux-gnu/bits/math-finite.h, which (I am guessing!) redfines sqrt as "__sqrt_finite".

Preston

-----Original Message-----
From: Benjamin Kramer [mailto:benny.kra< at >gmail.com] 
Sent: Tuesday, May 21, 2013 5:15 PM
To: Gurd, Preston
Cc: Chandler Carruth; Nadav Rotem; LLVMdev (LLVMdev< at >cs.uiuc.edu)
Subject: Re: [LLVMdev] Inlining sqrt library function in X86


On 21.05.2013, at 23:03, "Gurd, Preston" <preston.gurd< at >intel.com> wrote:


This sounds like your system headers are trying to outsmart the compiler, clang doesn't generate calls to __sqrt_finite anywhere. We may have to recognize the pattern in LLVM or clang if we want to inline calls to sqrt. A first step would be to figure out where the headers are doing this and whether there's a way to disable it.

- Ben

Re: make check for clang/llvm

David Blaikie — 2013-05-21T21:49:47


Can you explain the root cause? Is it just a matter of needing to pass some
particular arguments to llc to get the specific behavior Clang is relying
on?

- David


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

Re: make check for clang/llvm

Eric Christopher — 2013-05-21T21:49:25

No :)

Need more information. What's going on here?

-eric

make check for clang/llvm

reed kotler — 2013-05-21T21:38:38

I have a test that will only fail if I run clang and not if I run llc by 
itself but it's an llc issue.

Where would I put such a test?

Are there similar tests in the "make check" or "make check-all" suite?

Tia.

Reed

Re: Inlining sqrt library function in X86

Benjamin Kramer — 2013-05-21T21:14:34

On 21.05.2013, at 23:03, "Gurd, Preston" <preston.gurd< at >intel.com> wrote:


This sounds like your system headers are trying to outsmart the compiler, clang doesn't generate calls to __sqrt_finite anywhere. We may have to recognize the pattern in LLVM or clang if we want to inline calls to sqrt. A first step would be to figure out where the headers are doing this and whether there's a way to disable it.

- Ben