On Fri, Apr 27, 2012 at 9:24 PM, David Sehr <s...@google.com> wrote: > Hello All, > > We are using gcc trunk as of 4/27/12, and are attempting to add > support to the ARM gcc compiler for Native Client. > We are trying to get gcc -march=armv7-a to use movw/movt consistently > instead of minipools. The motivation is for > a new target variant where armv7-a is the minimum supported and > non-code in .text is never allowed (per Native Client rules). > But the current behavior looks like a generically poor optimization > for -march=armv7-a. (Surely memory loads are slower > than movw/movt, and no space is saved in many cases.) For further > details, this seems to only happen with -O2 or higher. > -O1 generates movw/movt, seemingly because cprop is folding away a > LO_SUM/HIGH pair. Another data point to note > is that "Ubuntu/Linaro 4.5.2-8ubuntu3" does produce movw/movt for this > test case, but we haven't tried stock 4.5.
I remember this one - this is https://bugs.launchpad.net/gcc-linaro/+bug/886124 and I reached the same conclusion as you did :) Unfortunately I've not been able to work out why such a change occurred and what's triggered this. Would you be able to experiment with some of the suggestions in that report and maybe create an equivalent one in the GCC bugzilla . I haven't had the time to investigate this particular problem further. regards, Ramana > > I have enabled TARGET_USE_MOVT, which should force a large fraction of > constant materialization to use movw/movt > rather than pc-relative loads. However, I am still seeing pc-relative > loads for the following example case and am looking > for help from the experts here. > > int a[1000], b[1000], c[1000]; > > void foo(int n) { > int i; > for (i = 0; i < n; ++i) { > a[i] = b[i] + c[i]; > } > } > > When I compile this I get: > > foo: > ... > ldr r3, .L7 > ldr r1, .L7+4 > ldr r2, .L7+8 > ... > .L7: > .word b > .word c > .word a > .size foo, .-foo > .comm c,4000,4 > .comm b,4000,4 > .comm a,4000,4 > > From some investigation, it seems I need to add a define_split to > convert SYMBOL_REFs to LO_SUM/HIGH pairs. > There is already a function called arm_split_constant that seems to do > this, but no rule seems to be firing to cause > it to get invoked. Before I dive into writing the define_split, am I > missing something obvious? > > Cheers, > > David
