[llvm] r234921 - IR: Set -preserve-bc-uselistorder=false by default

[Duncan P. N. Exon Smith]

> On 2015-Apr-14, at 20:22, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
>> On 2015-Apr-14, at 13:22, David Blaikie <dblaikie at gmail.com> wrote:
>> 
>> 
>> 
>> On Tue, Apr 14, 2015 at 1:18 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> 
>>> On 2015-Apr-14, at 12:41, David Blaikie <dblaikie at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Tue, Apr 14, 2015 at 12:25 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>> 
>>>> On 2015-Apr-14, at 11:53, David Blaikie <dblaikie at gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Tue, Apr 14, 2015 at 11:46 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>>> 
>>>>> On 2015-Apr-14, at 11:42, David Blaikie <dblaikie at gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Apr 14, 2015 at 11:33 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>>>> Author: dexonsmith
>>>>> Date: Tue Apr 14 13:33:00 2015
>>>>> New Revision: 234921
>>>>> 
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=234921&view=rev
>>>>> Log:
>>>>> IR: Set -preserve-bc-uselistorder=false by default
>>>>> 
>>>>> But keep it on by default in `llvm-as`, `opt`, `bugpoint`, `llvm-link`,
>>>>> `llvm-extract`, and `LTOCodeGenerator`.
>>>>> 
>>>>> Hmm - what's LTOCodeGenerator used for? If it's a standard library utility used in production pipelines it might make more sense for it to default-off & users can opt-in when necessary?
>>>> 
>>>> The usual flow for libLTO.dylib is "read bitcode, link, optimize, codegen,
>>>> write object".  Writing bitcode is used, e.g., by `ld -save-temps`.
>>>> 
>>>> LTOCodeGenerator is only used to actually generating bitcode from LTO-merged modules?
>>> 
>>> IIRC, that's the only time it outputs bitcode, so that's the only
>>> place `-preserve-bc-uselistorder` will have any effect.
>>> 
>>> I'm still a bit concerned about making that the default for what seems like a relatively common LLVM-as-a-library surface area.
>> 
>> Is it common?
>> 
>> Anyway, I don't understand the concern here.  I thought we'd agreed
>> that debug output should preserve use-lists?
>> 
>> I think I'm still agreeing - I'm just not sure this is strictly debug output. It seems like a generic utility (& relatively accessible library surface area for LLVM) that I'd hesitate baking "this is a debug tool" assumptions into.
> 
> I just think bitcode output during LTO is debug output.  I'll
> see how hard it would be to hook up new API to ld64 though; if
> it's easy enough then I don't mind exposing the bit through the
> LTO C API.

Done as of r235943.  It's better to be consistent, as you said, and
let the client decide.

As it turns out, once I got into it I noticed that ld64 *does* have
non-debug output of LTO -- if you specify the -r flag (an incremental
link which outputs a .o file) and all the input files are bitcode,
then the output file will be bitcode as well.

Thanks for the review!

> 
>> 
>> 
>>> 
>>>> Also, what's the deal with global state? (just realizing now that the "setPreserveBitcodeUseListOrder" is just a global function, not LLVMContext, etc) - that seems like the sort of thing I'd be even more inclined to push up into the actual utilities very directly, so there's no libraries quietly tweaking this global state in surprising ways.
>>> 
>>> Wrong as it may be, this sort of thing is pervasive in LLVM.
>>> 
>>> With varying degrees of "this is a hack & we'd like to remove it one day" depending on what it is exactly (eg: all the global state that we're trying to make module state for LTO semantics).
>>> 
>>> But if you have specific ideas, I'm happy to tweak this.
>>> 
>>> I'd imagine a parameter to "createBitcodeWriterPass" (& WriteBitcodeToFile) would be one way to avoid the global state in this instance.
>> 
>> I'm surprised at how few callers there are.  I'll have a go...
>