similar to: [LLVMdev] Pass to remove unused functions

On May 5, 2009, at 3:48 PM, Villmow, Micah wrote: > In order to handle a large vector based math library I link in a > fairly large bitcode file that might or might not be needed. The > problem is that linking in this bitcode file drastically increases > the amount of compile time required. Is there a way to remove all > functions that are not used after this linking pass?

I thought this pass would do it, but when I run it over my bc file the output file is the same as the input file. The issue I guess is a little different. When I link in the huge bc file with the tiny bc file, I only want the resulting bc file to have the function definitions that the tiny bc file requires and not every function in the huge bc file. Any idea's how to do this with the

Is there a way to mark all functions as internal from source via some sort of attribute? Thanks for the tips, Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, May 05, 2009 4:16 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Pass to remove unused functions On May 5, 2009, at 4:07 PM, Villmow,

On May 5, 2009, at 4:07 PM, Villmow, Micah wrote: > I thought this pass would do it, but when I run it over my bc file > the output file is the same as the input file. that's probably because your symbols are not internal. > > The issue I guess is a little different. When I link in the huge bc > file with the tiny bc file, I only want the resulting bc file to > have

On May 5, 2009, at 4:50 PM, Villmow, Micah wrote: > Is there a way to mark all functions as internal from source via > some sort of attribute? "static". However, if you do that, they won't make it into the bc file. -Chris > > Thanks for the tips, > Micah > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of

Yeah, I found that out, which is why I was hoping some kind of attribute existed that the compiler knew about. We might go the path of modifying llvm-link to only link in functions that are required as that seems to be the most optimal way of doing it. Thanks, Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, May 05,

On Thu, Dec 4, 2008 at 7:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 4, 2008, at 8:58 AM, Villmow, Micah wrote: > > What optimization pass promotes 32 bit math operations to 64 bit operations > so I can disable it? I have code that works fine with optimizations turned > off but fails with it turned on because of this stage. > > > Do you have a

Maybe it would be easier to provide a bitcode example of this problem. After thinking about this more, I'm not sure if this is applicable to SPIR itself. For you to have a constant GEP expression, you have to know the pointer size in order to correctly generate the expression. Since the pointer size itself is not known, I don't yet see how you can generate a constant expression that is

Micah, You're saying it works for you, but Clang doesn't currently anywhere near the range of horrible constantexpr constructs it is possible to create. You can "get by" at the moment with just handling ConstantGEPs, because of the way Clang works. But SPIR isn't restricted to Clang, and the problem is that it is *possible* (although not probable, or nice, but that is

Carlos, AMD's OpenCL implementation(both CPU and GPU) has worked for years with the way SPIR represents locals. If there is problems with the representation then it is an implementation issue. One of the issues with using extra kernel arguments is that it requires extra validation and complexity at the runtime level that is not needed if it is handled internally by the compiler. That being

On May 6, 2009, at 10:53 AM, Villmow, Micah wrote: > Yeah, I found that out, which is why I was hoping some kind of > attribute existed that the compiler knew about. > We might go the path of modifying llvm-link to only link in > functions that are required as that seems to be the most optimal way > of doing it. If you care about performance, then you should consider a

On Sep 28, 2012, at 9:45 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > You can easily simplify this problem with a restriction in SPIR: disallow ConstantExpr casts - no ptrtoint constant expression. Because GlobalVariables have pointer type, if you disallow converting their type to non-pointer type in a constantexpr, the number of constantexpr subclasses you have to deal with is

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Wednesday, October 07, 2009 5:50 PM > To: Villmow, Micah > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Instructions that cannot be duplicated > > On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > Is there a current

On Tue, May 5, 2009 at 7:47 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 5, 2009, at 4:50 PM, Villmow, Micah wrote: > > > Is there a way to mark all functions as internal from source via some sort > > of attribute? > > "static".  However, if you do that, they won't make it into the bc file. > -Chris A flag to force them into the .bc

Is there a current way to specify that an instruction or function call cannot be duplicated and thus any optimizations that might want to duplicate this instruction would fail? The problem deals with barrier in OpenCL 1.0. One of the conditions of using barrier is that if a barrier exists inside of control flow, every thread in a work-group must execute the barrier instruction(6.11.9).

> -----Original Message----- > From: Jeffrey Yasskin [mailto:jyasskin at google.com] > Sent: Thursday, October 08, 2009 11:09 AM > To: Villmow, Micah > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Instructions that cannot be duplicated > > On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > > > >

Yes, it would. But I was concerned Micah was just going to write it off as an implementation detail, so I felt that I should offer a "less correct but less work" option for him to consider. Cheers, James On 29 September 2012 03:16, Owen Anderson <resistor at mac.com> wrote: > > On Sep 28, 2012, at 9:45 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > >

On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Eli Friedman [mailto:eli.friedman at gmail.com] >> Sent: Wednesday, October 07, 2009 5:50 PM >> To: Villmow, Micah >> Cc: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Instructions that cannot be duplicated >>

On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Is there a current way to specify that an instruction or function call > cannot be duplicated and thus any optimizations that might want to duplicate > this instruction would fail? No. Anything can be duplicated. That could change, but you would need to make a strong case for why other solutions

On Thu, Oct 8, 2009 at 11:28 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Jeffrey Yasskin [mailto:jyasskin at google.com] >> Sent: Thursday, October 08, 2009 11:09 AM >> To: Villmow, Micah >> Cc: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Instructions that cannot be duplicated >>