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

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.

> 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).
I would be very surprised if glibc ever does. I don't have any
experience with eglibc.
> 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?
Take a look at gcc's implementation. They need to keep the order of
every definition they see. It also has other issues:

1654 	/* Output all functions, variables, and asm statements in the order
1655 	according to their order fields, which is the order in which they
1656 	appeared in the file. This implements -fno-toplevel-reorder. In
1657 	this mode we may output functions and variables which don't really
1658 	need to be output. */
> Regards,
> Sergey Y.
>

Cheers,
-- 
Rafael Ávila de Espíndola

Hi,
>> Are there any other issues?
> Take a look at gcc's implementation. They need to keep the order of
> every definition they see. It also has other issues:
> 1656    ... This implements -fno-toplevel-reorder. In
> 1657    this mode we may output functions and variables which don't
really
> 1658    need to be output. */
Ok, option support requires to keep order of definitions and for some
reason that is undesirable in LLVM.
Then, it would be helpful to get at least some diagnostic message from
llvm-gcc on unsupported option.

Regards,
Sergey Y.