[PATCH] Update API to add PIC-level support.

[Eric Christopher]

I meant using the named metadata for module flags:

llvm.module.flags

and adding an entry and merge support for the particular metadata for flag_pic.

Though, in general, non-mergeable code generation flags like this
should be at the module scope and we can possibly come up with another
way of encoding them.

-eric


On Thu, Oct 9, 2014 at 10:54 PM, Justin Hibbits <jrh29 at alumni.cwru.edu> wrote:
> Do you mean add methods to llvm::Module class, as, say,
> setPICLevel()/getPICLevel(), and set it from clang?  If so, that's a
> much less intrusive patch than this.  I think I can get the Module
> pointer when in the AsmPrinter, but what about in, say,
> PPCTargetLowering?  If I can always find the Module, then this will be
> an easy change.
>
> - Justin
>
> On Wed, 8 Oct 2014 16:43:12 -0700
> Eric Christopher <echristo at gmail.com> wrote:
>
>> So the general comment here is that the pic level should be module
>> dependent and merge according to whichever is "least pic-like". Can
>> you make this a module level attribute that's looked up and merge that
>> way?
>>
>> At which point I'm not sure whether or not the plumbing you've done
>> here makes sense versus grabbing it otherwise.
>>
>> Thoughts?
>>
>> -eric
>>
>> On Mon, Oct 6, 2014 at 12:21 AM, Eric Christopher
>> <echristo at gmail.com> wrote:
>> > I'll look at this today.
>> >
>> > On Fri, Oct 3, 2014 at 11:12 PM, Justin Hibbits
>> > <jrh29 at alumni.cwru.edu> wrote:
>> >>>>! In D5332#9, @mcrosier wrote:
>> >>> Just a few nits.
>> >>>
>> >>> (If this isn't already being done in another patch) Can you add
>> >>> some amount of functionality, so this can be tested in some
>> >>> trivial way?
>> >>>
>> >>> Unfortunately, I'm not the right person to sign off on this..
>> >>
>> >> Thanks for reviewing.  This is just the plumbing patch.  The real
>> >> meat (the reason I created this in the first place) is in D5399,
>> >> adding -fpic (small-model PIC) to PowerPC.  This is accompanied by
>> >> tests.
>> >>
>> >> This patch itself should have no impact on functionality, only on
>> >> API usage, which D5400 demonstrates for Clang.  So, really, D5400
>> >> and this belong together, since Clang breaks without the patch in
>> >> D5400.
>> >>
>> >> http://reviews.llvm.org/D5332
>> >>
>> >>
>