This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SSA usage question


    GIMPLE is not supposed to be powerful.  It's supposed to be really
    simplistic to cater to the optimizers.  You are supposed to expose
    everything in excruciating detail.

That's nice in theory, but sometimes reality gets in the way and that's
what's happening here.  As I said yesterday, everything is easy if you ignore
the hard cases!  These complex trees are indeed the hard cases and the
design needs to be worked around *them*, not the easy cases where everything
is constant and there are no conversions in the tree of references.

A major issue is the highest_pow2_factor function in expr.c.  That's
required in order to know if copies need to be done during the evaluation
of references due to unaligned accesses.

But in order for that to work, it has to see the entire expression.  If it's
broken into piece, it won't survive to the needed level.

This is one of many reasons why I think GIMPLE has to defer handling things
in references and leave it to the expander phases.

Otherwise, we have to have all sorts of kludges where we annotate various of
information in a the sort of GENERAL_REF that RTH suggested yesterday.  It
would indeed have to include the alignment (as I hadn't realized yesterday).
We can also record the list of fields gone through (for RTL-level aliasing
info) there, the type to use for aliasing information (depending on bitfield
or addressability status of the underlying fields), and perhaps some data to
help the array optimizers figure out that this used to be an array reference.

I suppose I could do this if there were no other way ...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]