gmane.comp.compilers.llvm.devel

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. Wh

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

Re: Inlining sqrt library function in X86

Gurd, Preston — 2013-05-21T21:03:00

Thanks for the fix!

However, there still seems to be a problem in that if you pass  –ffast-math to clang, then clang changes “sqrt” to be “__sqrt_finite”. LLVM cannot then change the function call into an x86 sqrt instruction, even with –fno-math-errno set.

Can you suggest where I might look in the clang code to find the place where “sqrt” is converted to “__sqrt_finite” and/or the best way to solve this problem?

Thanks,

Preston

From: llvmdev-bounces< at >cs.uiuc.edu [mailto:llvmdev-bounces< at >cs.uiuc.edu] On Behalf Of Chandler Carruth
Sent: Saturday, May 18, 2013 4:48 PM
To: Nadav Rotem
Cc: LLVMdev (LLVMdev< at >cs.uiuc.edu)
Subject: Re: [LLVMdev] Inlining sqrt library function in X86

On Sat, May 18, 2013 at 5:18 PM, Nadav Rotem <nrotem< at >apple.com<mailto:nrotem< at >apple.com>> wrote:
Does fast-math imply no-math-errno ?

Yes, in both GCC and Clang. Clang does have some annoying logic bugs surrounding this flag though. For example, setting -fno-fast-math would imply no-math-errno,

Re: Static linking of execution engine

Kaylor, Andrew — 2013-05-21T19:57:19

Yeah, this is a problem with the static constructor getting optimized out.  Including "JIT.h" is supposed to fix that.

Is it possible that the file where you are including "JIT.h" doesn't have any required code in it?

-Andy

-----Original Message-----
From: llvmdev-bounces< at >cs.uiuc.edu [mailto:llvmdev-bounces< at >cs.uiuc.edu] On Behalf Of Mario Schwalbe
Sent: Tuesday, May 21, 2013 4:52 AM
To: LLVM Devel
Subject: [LLVMdev] Static linking of execution engine

Hi,

I'm on Linux and trying to link an application that makes use of LLVM's JIT execution engine statically.

Setup:
(1) LLVM libs are compiled as static libraries.
(2) Called InitializeNativeTarget().
(3) Included llvm/ExecutionEngine/JIT.h.

It works if I build and link regularly.

However, if I add -static when linking, the execution engine fails to initialize. Does anyone know why? LLVM libs are already archives. Is that supported at all?

Thanks & ciao,
Mario
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.e

Is it valid to add parameters to a function once it iscreated

Frank Winter — 2013-05-21T19:19:08

I create a function with an empty signature:

   void llvm_start_new_function() {
     llvm::outs() << "Staring new LLVM function ...\n";

     Mod = new llvm::Module("module", llvm::getGlobalContext());
     builder = new llvm::IRBuilder<>(llvm::getGlobalContext());

     llvm::FunctionType *funcType = 
llvm::FunctionType::get(builder->getVoidTy(), false);
     mainFunc = llvm::Function::Create(funcType, 
llvm::Function::ExternalLinkage, "main", Mod);

     llvm::BasicBlock* entry = 
llvm::BasicBlock::Create(llvm::getGlobalContext(), "entrypoint", mainFunc);
     builder->SetInsertPoint(entry);

     llvm_counters::param_counter = 0;
     llvm_counters::label_counter = 0;
   }

and then add parameters as needed with something like

     llvm::Argument * u8 = new llvm::Argument( 
llvm::Type::getInt8Ty(llvm::getGlobalContext()) , param_next() , mainFunc );

Is this valid?

Re: malloc / free & memcpy optimisations.

Duncan Sands — 2013-05-21T18:50:11

Hi Jeremy,

On 21/05/13 14:34, Jeremy Lakeman wrote:

the optimizer that does memcpy forwarding is in
   lib/Transforms/Scalar/MemCpyOptimizer.cpp
You might want to look into teaching it how to handle malloc'd memory and not
just alloca instructions.  I think the logic is in
   MemCpyOpt::performCallSlotOptzn

Ciao, Duncan.

Re: malloc / free & memcpy optimisations.

Philip Reames — 2013-05-21T16:00:17

I have been playing with some ideas in this space.  I haven't gotten beyond toy implementations yet, but would be happy to brainstorm if nothing else. 

I'm traveling at the moment, but should have some time next week if you want to discuss.  

Philip Reames

----
Apologies for any terseness; typing on a phone's keyboard does not lend itself to verbosity. 

On May 21, 2013, at 7:15 AM, Jeremy Lakeman <Jeremy.Lakeman< at >gmail.com> wrote:

Mixing noalias and regular arguments

Kuperstein, Michael M — 2013-05-21T15:23:07

Hi all,

I'm trying to understand the semantics of noalias arguments, and I'm not entirely sure I got it correctly.
To the best of my understanding, if an argument is declared noalias, "This indicates that pointer values based on the argument do not alias pointer values which are not based on it" implies, among other things, that it cannot alias any other argument, even if that argument is NOT declared noalias.
However, currently, BasicAliasAnalysis doesn't recognize this case explicitly. Sometimes it will work for other reasons (e.g. if it knows the other argument does not get captured), but it's relatively easy to get circumstances where the result is MayAlias.

I'm attaching a patch that addresses this.
Can anyone offer an opinion on the basic issue and, assuming this is the desired behavior, on the patch?

Thanks,
   Michael

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use o

Re: subtle issue with soft-float and new attribute scheme (possibly an issue with other attributes)

Rafael Espíndola — 2013-05-21T14:05:25

Because all the information will be available in the attributes. If,
for example, codegen can decide on hard float or soft float for a
function based on an attribute, clang can set it and the default when
the attribute is not present is mostly arbitrary (mostly because of
backwards compatibility considerations).

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: debugging llvm from clang using gdb

reed kotler — 2013-05-21T13:33:37

That did it. Thanks.

That's how I debug clang itself. I'm not using my head right now. :)

Reed

On 05/21/2013 05:35 AM, Reid Kleckner wrote:

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

Re: debugging llvm from clang using gdb

Tim Northover — 2013-05-21T12:35:49

Hi Reed,


This is usually because clang forks off a process to do the actual
work. Try executing "set follow-fork-mode child" in gdb before running
clang.

I vaguely remember that running gdb against the "clang -cc1" command
works too (sometimes), but it's so rare that something is only
clang-debuggable that I've forgotten the details.

Cheers.

Tim.

Re: debugging llvm from clang using gdb

Reid Kleckner — 2013-05-21T12:35:38

Are you debugging the driver process or the -cc1 process?  To get the -cc1
process, unfortunately you have to go through the dance of passing -### to
get the -cc1 line and then run that in gdb (or write one manually).
 Alternatively in gdb you can say "set follow-fork child" (or something,
check the docs) to automatically follow into the -cc1 child.


On Tue, May 21, 2013 at 8:00 AM, reed kotler <rkotler< at >mips.com> wrote:

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

Re: malloc / free & memcpy optimisations.

Jeremy Lakeman — 2013-05-21T12:34:57

This is mainly for string or binary blob handling, using the stack isn't a
great idea for size reasons.

While I'm experimenting with simple code examples now, and I picked a
simple one for this email. I'm certain things will get much more
complicated once I implement more features of the language.


On Tue, May 21, 2013 at 8:45 PM, Jeremy Lakeman <Jeremy.Lakeman< 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

debugging llvm from clang using gdb

reed kotler — 2013-05-21T12:00:56

I've always debugged the backend llc by running it as a separate executable.

I'm seeing a bug that only happens when I run the compiler from clang.

How do you debug this from gdb?

I can put a breakpoint but it never stops when I say "run ...."

Tia.

Reed

Re: malloc / free & memcpy optimisations.

Duncan Sands — 2013-05-21T11:57:34

Hi Jeremy,

On 21/05/13 13:15, Jeremy Lakeman wrote:

could you allocate the memory on the stack instead (alloca instruction)?

Ciao, Duncan.

Re: Trunk fails to compile on PPC64 Linux

İsmail Dönmez — 2013-05-21T11:55:06

Hi,

Reported http://llvm.org/bugs/show_bug.cgi?id=16086

Thanks!

On Mon, May 20, 2013 at 5:52 PM, Hal Finkel <hfinkel< at >anl.gov> wrote:

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

Static linking of execution engine

Mario Schwalbe — 2013-05-21T11:52:20

Hi,

I'm on Linux and trying to link an application that makes use of
LLVM's JIT execution engine statically.

Setup:
(1) LLVM libs are compiled as static libraries.
(2) Called InitializeNativeTarget().
(3) Included llvm/ExecutionEngine/JIT.h.

It works if I build and link regularly.

However, if I add -static when linking, the execution engine
fails to initialize. Does anyone know why? LLVM libs are already
archives. Is that supported at all?

Thanks & ciao,
Mario