llvm dev - Feb 2010 - [LLVMdev] how to build eglibc using llvm-gcc without unsupported -fno-toplevel-reorder

Hi,

llvm doesn't support -fno-toplevel-reorder option which affects
glibc/eglibc for some targets.
http://www.llvm.org/bugs/show_bug.cgi?id=6364
>From conversations with gcc and eglibc maintainers, seems option is
highly expected and is not going to deprecate.
>> 2010/2/23 Ian Lance Taylor <iant at google.com>:
>> If option is going to deprecate in gcc in near future as well, than it
>> make sense to consider changes in glibc(eglibc).
>> So, there are no plans to deprecate option. Did I understand correctly?
> Correct.  There are no plans to deprecate the -fno-toplevel-reorder
> option.
Are there any reasons why option can't be supported by llvm?

Regards,
Sergey Yakoushkin

2010/2/22 Török Edwin <edwintorok at gmail.com>:
> On 2010-02-21 23:36, Sergey Yakoushkin wrote:
>> Hi, Rafael
>>
>> Inlined asm markup inside functions and on the top level is used to
>> split asm prologue/epilogue parts in very fine-grained manner.
>> So, splitting source c won't give the same result.
>
> You could have 2 files:
>  - 1 which contains the function, and a marker where prolog ends
> (beginning of file is implicit marker of where it begins)
>  - 1 which contains the function, and a marker where epilog begins
> (end of file is implicit marker of where it ends)
>
> Or just look at ./sysdeps/x86_64/elf/initfini.c, its a single asm()
> block containing all relevant markers, and no C code.
> I think thats better than all these hacks to get the asm you want out of
> C code.
>
> Best regards,
> --Edwin

> Are there any reasons why option can't be supported by llvm?
It is hard and has very few users. For this to work you would have to
add ordering information to the LLVM IL. It looks easier to patch
eglibc.
> Regards,
> Sergey Yakoushkin
Cheers,
-- 
Rafael Ávila de Espíndola

Hi,
>> Are there any reasons why option can't be supported by llvm?
> It is hard and has very few users. For this to work you would have to
> add ordering information to the LLVM IL. It looks easier to patch
> eglibc.
I agree, impact of issue is limited. But it prevents out of the box
compilation of libraries for some targets.
Also, looks like glibc and eglibc maintainers do not welcome patches
for llvm (yet).

In general, saving order of appearance doesn't seem to be bad thing.
Are there any technical issues with addition of ordering?
I guess class Module and it's uses in parser (and linker) will be
mostly affected.
Currently Module stores different entities separately and concatenates
all top level asm into single string.
  FunctionListType FunctionList; ///< The Functions in the module
  std::string GlobalScopeAsm;    ///< Inline Asm at global scope.

Are there any other issues?

Regards,
Sergey Y.