similar to: [LLVMdev] [RFC] Embedding command line options in bitcode (PR21471)

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

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

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

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

There are parts of this proposal that I really like, and there are others that I think are actually at opposition to the work we’re trying to do with cl::opt. > 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

> On 2014-Nov-14, at 13:58, Eric Christopher <echristo at gmail.com> wrote: > > Hi Akira, > > This is very closely related to the work I've been doing and so I care quite a bit about it. I've implemented some of this - at least as far as the global TargetMachine options in the current work for Subtarget code generation - which is what some of this comes down to.

I've been investigating what is needed to ensure command line options are passed to the backend codegen passes during LTO and enable compiling different functions in a module with different command line options (see the links below for previous discussions). http://thread.gmane.org/gmane.comp.compilers.llvm.devel/78855 http://thread.gmane.org/gmane.comp.compilers.llvm.devel/80456 The command

To continue the discussion I started last year (see the link below) on embedding command-line options in bitcode, I came up with a plan to improve the way the backend changes UnsafeFPMath on a per-function basis. The code in trunk currently resets TargetOptions::UnsafeFPMath at the beginning of SelectionDAGISel::runOnMachineFunction to enable compiling one function with “unsafe-fp-math=true” and

(forwarding to llvm-dev) ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Fri, Aug 17, 2012 at 2:35 PM Subject: Re: [LLVMdev] MIPS & GP register To: Carl Norum <carl at lytro.com> Will something like this fix the problem? if (!Subtarget.isLinux()) { reserve GP and GP_64 } To improve code, we have stopped reserving GP as a dedicated

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH]

On 09/23/2015 08:48 AM, Akira Hatanaka wrote: > On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > To be clear, this is a debuging aid only? It's not something > required for correctness? I'm somewhat bothered by that because > it seems like it would be a useful

Yes, I see the load is 8-byte aligned in the bit code. My question was, assuming that arguments requiring double word alignment have to be passed in even/odd registers, how does the backend know that %0 has to be passed in register r2 and r3? *tail call arm_aapcscc void (i32, ...)* @foo0(i32 1, [2 x i32] %0) nounwindt * It doesn't seem that ARM backend can figure out that "[2 x i32]

On 09/24/2015 01:47 PM, Akira Hatanaka wrote: > On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > > On 09/23/2015 08:48 AM, Akira Hatanaka wrote: >> On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames >> <listmail at philipreames.com <mailto:listmail at

On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> >> To: "Akira Hatanaka" <ahatanak at gmail.com> >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> >>

+llvm-dev Can you give a bit of background on what you're trying to address here? After reading through the discussion and seeing that this is a best effort flag, I'm not sure that a function attribute is the best way to describe this. I'm open to being convinced it is, but I'd like to hear a bit more about the use case and get broader visibility on the proposal first.

To be clear, this is a debuging aid only? It's not something required for correctness? I'm somewhat bothered by that because it seems like it would be a useful implementation tool for higher level languages. A couple of thoughts in no particular order: 1) Can we always annotate the call site rather than the function? That removes the unpredictability due to optimization. 2) Calling