Re: Add -fsection-anchors (4.2 project)

[Mark Mitchell <mark at codesourcery dot com>]

Richard Sandiford wrote:
> Thanks for the review.  You asked for feedback on the -Ox thing (although
> I suspect you'll wish you hadn't), so here goes...

:-)

> If you're not convinced that it's so target-dependent, consider that
> powerpc64-linux-gnu uses the GOT for most symbol accesses, including
> non-PIC accesses to locally-binding symbols. 
> 
> But on powerpc32-linux-gnu, executables can use high/low accesses to
> compute a locally-binding symbol.

If you have base+offset addressing, does using a section anchor actually
hurt you?  I would have thought that you would just end up with an
offset on each load/store instruction.  (I don't know if that causes the
instruction to take more cycles or use more function units, though.)

On an architecture without base+offset addressing, like Itanium, anchors
would lose, if you have the ability to synthesize addresses in two
instructions, and you only have one address.

However, even there, I'd expect you'd be better off by exposing the
section anchor to the compiler, and then, if there were only one address
required, converting it back to a direct calculation.  Fundamentally,
the placing of data into blocks is giving the compiler strictly more
information.  Maybe what I should argue is that we should always place
data into blocks, even if we don't actually use the anchor for code
generation.

In any case, I think I'm out of my depth.  I'm happy to leave it to the
PowerPC maintainers to determine whether or not the option should be
enabled there.

> However, there's no such penalty when you're using things like high/low
> accesses. or per-function constant pools.  Targets that use those sorts
> of access would probably do better if we reused addresses that the
> function has to calculate anyway.

That's a good idea, for a future improvement.

>>Below, you clear flag_section_anchors for !flag_unit_at_a_time, as well;
>>shouldn't that result in the warning as well?
> 
> This was deliberate, but I forgot to mention it, sorry.  The reasoning
> was that both the target and the -fsection-anchors setting are things
> that the user has specifically chosen, so a warning seemed appropriate.
> However, -funit-at-a-time is partly compiler-controlled, so the decision
> seemed less clear-cut.
> 
> For example, I can imagine makefiles that compiled both Java and C++
> code, and that want to use the same optimisation options for both.
> If we warned about -fno-unit-at-a-time being incompatible, we'd get
> the warning for every Java compilation.

That's a hard call.  I tend to disapprove when the compiler doesn't tell
me it's ignoring something I explicitly asked it to do, and I'd be
willing to tweak my Makefiles to work around the situation you mention,
but maybe other people are biased in the other direction.  I'm content
with your version; if a clear consensus arises otherwise, then we can
change it.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713