> On Tue, Jun 12, 2012 at 03:57:44PM +0000, Jay K wrote:
> >
> > Our front end is wierd.
> > The input is unusually low level, and so are the trees it produces.
> > I do have a hankering to fix that (or maybe just to output more portable
C...)
> > But for now:
> > It doesn't use component_refs, and doesn't
> > define types much, but uses either
> > either (type*)(base + offset) or bitfield_ref(base, offset, size).
> >
> > As such, it runs into occasional problems.
> > I have had to turn off various optimizations with e.g.:
> > flag_tree_sra = false
> > in langhook_post_options.
> >
> > Looking at this briefly, I think I see one of the problems.
> > tree-sra.c looks for component_refs to bitfields, but
> > it doesn't look for bitfield_refs. It should?
>
> I am not sure what you mean, if you search for the sting BIT_FIELD_REF
> in tree-sra.c, you'll quickly find the places where we "look for" them
> (or perhaps I should write look through them). The most important
> ones are in functions build_access_from_expr_1 and especially
> sra_modify_expr.
>
> Having said that, Andrew Pinski has reported problems with SRA's
> handling of BIT_FIELD_REF in another special setup, so perhaps you
> have similar problems. Please have a look at the thread starting with
> message: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00009.html
>
> So far it however looks that, if we ever come across such problems on
> trunk, we'll disable SRA for aggregate parts which are written to by a
> BIT_FIELD_REF on a left hand side, mainly because we do not consider
> them important for performance critical code.
>
> Thanks,
>
> Martin
create_access is where I noticed it.
Yeah, I know my report is vague and crummy.
Maybe I should put together somesuch "hardcoded tree frontend" to demonstrate
it.
I don't think the trees I'm thinking of are producible from C, unless maybe
via a gcc extension?
I'll look later..like..I wonder where BIT_FIELD_REF would be used at all in a
normal frontend.
If I can find one, I'll maybe try to put together a test case for it.
We do use them for reads and writes.
Even for things like picking out exponent/mantissa from floats .. well, it
used to.
I changed it to prefer *(type*)(base + offset) when either base or type is
floating point.
Longer story:
I changed to use *(type*)(base + offset) for floating point because we used
to make
everything addressable/volatile. Then all optimizations "worked" -- no
internal compiler
errors, bus errors, etc., but of course the code quality stunk. Though better
with bit_field_ref
than *(type*)(base + offset).
In removing the addressable/volatile, I then had to work through
the compiler errors, incorrect code, etc., disabling optimizations
selectively,
changing our trees some.
I understand we generate weird trees, so I try not to complain too much.
Thank you,
- Jay
