[RFC] make arm-use-movt and arm-reserve-r9 options available for all arm

[Jeroen Hofstee]

Hello Renato,

On 08/12/2013 08:36 PM, Renato Golin wrote:
> On 12 August 2013 18:31, Jeroen Hofstee <llvm at myspectrum.nl 
> <mailto:llvm at myspectrum.nl>> wrote:
>
>     U-boot uses 'register volatile gd_t *gd asm ("r8")' to access data
>     which needs
>     to be available before and after relocation. This is a global
>     definition and gcc
>     is compiled with -ffixed-r8 in order to prevent using r8.
>
>
> Ok, it's better than I feared, but worse than I hoped for.
>
> Why is U-boot using R8 and not R9 as described in the AAPCS?
>
> After a few Google searches, it seems that -ffixed-r8 seems to be 
> (almost?) exclusively used by u-boot, which is worrying, and not the 
> kind of thing LLVM wants to implement. But, as you say, keeping R9 
> ARM-wide fixed is an AAPCS rule, so we're in the safe there.
>

Don't worry nor fear, see 
http://lists.denx.de/pipermail/u-boot/2013-August/160604.html

> From an EABI point of view, I'm happy with making that flag global, 
> but you'll have to juggle Clang vs. LLVM patches to keep breaking 
> stuff to a minimum.

Yes, that is why proposed to send both patches through llvm-commits, so it
can be applied at the same time to keep the bots and users happy.

> You'll also have to check with Darwin folks if that's ok with them as 
> well.

I did on IRC and is on cc. And besides the rename of the hidden flag, 
nothing changed for IOS.
>
>         __asm__ volatile("mov %0, r9\n" : "=r" (gd_ptr));
>
>
> This should also work with GCC without the -ffixed-r8 flag, but with 
> the respective AAPCS variant for R9, right? It sounds like a good 
> patch for u-boot.
>

Well not in this shape, it will treat clang and gcc differently (there 
is no reason to
punish gcc for clang not supporting global registers), to keep current 
behaviour
for U-boot (but a bit of topic here). Scheduled for the next merge 
window after
I have the llvm patches in.
>
>     See above, and the initial commit. I want r9 to always be left
>     alone. IOS doesn't
>     for some reasons I do not know, but it is not for AAPCS. (and if I
>     have to guess,
>     it is related to their r9 usage depending on the target).
>
>
> I have to say, I'm a bit lost on the v6 thing. I don't mind much how 
> you're going to use it as long as you don't change the current 
> behaviour on all platforms (ie. don't change the default flag status 
> on Clang or the default state on LLVM for any target).
>
Nothing changes, only arm on non IOS gets a new hidden flag.

>
>     No, not manually at least, just build it on Linux and verified
>     u-boot works.
>
>
> This is good news, but not enough. After you build Clang/LLVM, do a 
> "make check-all". That will cover the basics, and hopefully there will 
> be tests on the R9 behaviour for Darwin.

make check-all output:

Testing Time: 40.08s
   Expected Passes    : 13181
   Expected Failures  : 53
   Unsupported Tests  : 1724

> But that's still very limited, so it'd be good to run the test-suite 
> to make sure that the correct flags are being passed down on complex 
> build environments (ie. to check for regressions).
>
> This is the test-suite how to, it's very simple:
> http://llvm.org/docs/lnt/quickstart.html
>
> AFAIK, you can't run them cross to ARM, so you'll have to run it on an 
> ARM board. You can cross-compile Clang/LLVM and copy the install dir 
> to the board and point the --cc and --cxx to that, or you can build 
> Clang/LLVM on the board itself (easier, but takes longer).
>
> Here are some instructions on how to build it on ARM (to limit the 
> number of stuff you have to compile):
> http://llvm.org/docs/HowToBuildOnARM.html
>
> If you're building it natively, make sure you "make check-all", too.
>
> FYI, a Chromebook build on those conditions takes about 50 min to 
> build + 10 min for check-all + 1 hour for the test-suite.
>
mmm, this is a bit more difficult since the target has no compiler and 
only 512Mb flash.
>
>     I grepped for the usage of these flags inside llvm / clang, but
>     there is
>     nothing interesting there. I do not have a darwin / ios build env.
>
>
> This could be one of the features that is interesting to Apple only, 
> Jim can comment on that better than me. He could also test your patch 
> locally on Darwin targets.
>
Yes, the rename of the Darwin flag is the only concern to me. Which Jim 
said was fine, just asking for confirmation.

Regards,
Jeroen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130812/2a8ec691/attachment.html>