similar to: [LLVMdev] [RFC] Storing default function attributes on the module

+grosbach > On 2015-Feb-12, at 14:45, Reid Kleckner <rnk at google.com> wrote: > > Are llc command line options all that critical? It's not that hard to edit the attributes directly or remove them with sed. Maybe Jim can speak to this one better than I can, but the workflow I've heard concerns about is: - Got a codegen bug (PR or whatever). - Want to fiddle with

Hi Duncan The first patch is general goodness and I think should be committed now. The other 2 LGTM. Unless anyone fundamentally objects to module attributes, or has feedback on the patches themselves, then please commit. I didn’t see any problems with them. Thanks, Pete > On Feb 12, 2015, at 4:02 PM, Jim Grosbach <grosbach at apple.com> wrote: > > >> On Feb 12, 2015,

Hi Duncan, Been thinking about this a bit and a few comments/questions. I may have misunderstood some things in your mail though so please feel free to explain at me :) > Changing `clang` to store target defaults on the module will allow us to > continue to override them when running `llc`. The right precedence > would be: > > 1. Explicit attributes set on the function. >

On Tue, Feb 24, 2015 at 2:53 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-Feb-24, at 13:25, Eric Christopher <echristo at gmail.com> wrote: > > > > Hi Duncan, > > > > Been thinking about this a bit and a few comments/questions. I may have > misunderstood some things in your mail though so please feel free to >

On Tue, Feb 24, 2015 at 3:18 PM Sean Silva <chisophugis at gmail.com> wrote: > On Tue, Feb 24, 2015 at 2:53 PM, Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > >> >> > On 2015-Feb-24, at 13:25, Eric Christopher <echristo at gmail.com> wrote: >> > >> > Hi Duncan, >> > >> > Been thinking about this a bit and

> On Mar 5, 2015, at 1:01 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> On 2015 Feb 26, at 11:34, Eric Christopher <echristo at gmail.com> wrote: >> >> >> >> On Tue, Feb 24, 2015 at 3:18 PM Sean Silva <chisophugis at gmail.com> wrote: >> On Tue, Feb 24, 2015 at 2:53 PM, Duncan P. N. Exon Smith

Hi, It looks like SimplifyLibCalls has a tendency to emit calls to libm functions without checking with TLI whether these calls are available. For example, PowOpt has this code: struct PowOpt : public UnsafeFPLibCallOptimization { PowOpt(bool UnsafeFPShrink) : UnsafeFPLibCallOptimization(UnsafeFPShrink) {} virtual Value *callOptimizer(Function *Callee, CallInst *CI, IRBuilder<> &B)

On Tue, Aug 13, 2013 at 5:58 AM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > Hi,**** > > ** ** > > It looks like SimplifyLibCalls has a tendency to emit calls to libm > functions without checking with TLI whether these calls are available.**** > > For example, PowOpt has this code:**** > > ** ** > > struct PowOpt : public

Updated patch is attached. Note this is just a work-in-progress patch and I plan to address the feedback comments later if this patch is in the right direction. This is how the command line options are parsed and used by the backend passes: 1. Tools such as clang and llc call cl::ParseCommandLineOptions. Any of the options that should be written to the bitcode as function or module attributes

On Wed, Nov 19, 2014 at 3:28 PM, Eric Christopher <echristo at gmail.com> wrote: > So my general concern here is that lots of command line options that don't > need to be or shouldn't be IR level constructs become oddly named string > options. It's bad enough that we're doing that with the target cpu and > target feature string let alone the rest of it. > >

> On Nov 19, 2014, at 4:52 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Wed Nov 19 2014 at 4:39:42 PM Akira Hatanaka <ahatanak at gmail.com <mailto:ahatanak at gmail.com>> wrote: > On Wed, Nov 19, 2014 at 3:28 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: > So my general concern here is

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

Thanks for your feedback, Eric. I still think we may be talking past each other a little bit, but rather than delving further into the details right now, I’ve suggested to Akira that he look into how we should handle other kinds of options. I’m hoping that as we look at more of them, we will gain some insight into the approach that we want to take here. This patch really only deals with the easy

> On Nov 14, 2014, at 2:44 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > +chrisb > >> On 2014-Nov-13, at 16:33, Akira Hatanaka <ahatanak at gmail.com> wrote: >> >> I'm working on fixing PR21471, which is about embedding codegen command line options into the bitcode as function or module-level attributes so that they don't get

On Tue, Dec 2, 2014 at 3:21 PM, Eric Christopher <echristo at gmail.com> wrote: > On Mon Dec 01 2014 at 4:22:15 PM Bob Wilson <bob.wilson at apple.com> wrote: > >> Thanks for your feedback, Eric. >> >> I still think we may be talking past each other a little bit, but rather >> than >> > > Might be, sorry if so :( > > >> delving

I'm trying to find a way to get/set the module attributes as printed in a module dump: attributes #0 = { noinline nounwind uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"

On Tue, Dec 2, 2014 at 4:38 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Tue Dec 02 2014 at 4:31:43 PM Akira Hatanaka <ahatanak at gmail.com> > wrote: > >> On Tue, Dec 2, 2014 at 3:21 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> >>> On Mon Dec 01 2014 at 4:22:15 PM Bob Wilson <bob.wilson at apple.com>

On Fri, Dec 5, 2014 at 2:40 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Wed Dec 03 2014 at 11:39:23 AM Akira Hatanaka <ahatanak at gmail.com> > wrote: > >> On Tue, Dec 2, 2014 at 4:38 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> >>> >>> >>> On Tue Dec 02 2014 at 4:31:43 PM Akira Hatanaka

Hi, [Apologies to those receiving this mail twice - used the old list address by accident] In LLVM it is currently not possible to write a Module-level pass (a pass that modifies or analyzes multiple MachineFunctions) after DAG formation. This inhibits some optimizations[1] and is something I'd like to see changed. The problem is that in the backend, we emit a function at a time, from DAG

Hi, I’d like to support string attributes on function arguments and return values. We are going to use them in our tree to express higher level language types. Internally attributes framework have everything to do this, it’s even possible to generate string attributes via API right now: Function *function; function->setAttributes(function->getAttributes().addAttribute(context, i,