Zdenek Dvorak wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the virtual operands for TARGET_MEM_REFs the same
as before the transformation (unless that got broken in last few months,
which unfortunately is pretty likely).
It would be better to annotate things with better alias information
than transform into target specific trees, which none of the other
transformations actually know how to deal with.
well, I had impression that what he does is some target-specific
transformation, so this idea did not seem all that out of place to me.
Thanks Daniel and Zdenek for your suggestions!
In principle, I don't see anything forbidding Zdenek's idea.
Unfortunately, what I avoided to mention is that TARGET_MEM_REF nodes
are also transformed into pointer arithmetics and the equivalent
INDIRECT_REF memory access... therefore, this is not an option even only
because of that.
I will investigate about the attribute idea.
In the previous example of transformed code:
cilsimp.1 = &s.a[0];
D.1423 = i.0 * 4;
D.1424 = D.1423 + cilsimp.1;
*D.1424 = 1;
would you attach such an attribute to the INDIRECT_REF involving D.1424?
My only concern is the effort to put in the existing GIMPLE passes in
order that they properly deal with the attribute. Perhaps, I'm
over-estimating it and it's just a matter of extending get_alias_set (...).
To say more about this specific problem:
The first time this CLI-specific transformation is performed is before
GIMPLE code enters SSA form (while it is also run after out-of-ssa to
make sure everything is fine right before the bytecode emission).
The output of the transformation is still valid GIMPLE (for the sake of
precision, a subset of valid GIMPLE, since some constructs are
simplified... as shown) and it will go through all the existing
middle-end passes.
Cheers,
Roberto
