This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gfortran] Complex type components
Paul Brook <paul@nowt.org> writes:
| On Wednesday 10 September 2003 12:50 am, Gabriel Dos Reis wrote:
| > Paul Brook <paul@nowt.org> writes:
| > | We currently get gimplification failures when taking the real or
| > | imaginary part of a comples expression. Example:
| > | {
| > | complex z;
| > | double r;
| > | r = __real__ (z*z)
| > | }
| > |
| > | The patch below makes the gimplifier mandle these like component
| > | references, rather than array refs.
| >
| > please could you elaborate on the actual optimisation wins? I would
| > think that an array ref would give a better non-aliasing attribute.
|
| The difference is whether we require an lvalue, or accept rvalues when
| gimplifying.
I see.
| I don't know how all the aliasing stuff works, but a component
| ref would seem to be a closer match than an array ref.
what I wanted to say is that, given an array and two indexes i and j
with i != j, we know that array[i] cannot alias array[j]. Is that
also true for component refs?
| > | I'm not sure if this was originally an oversight or
| > | a deliberate decision - they aren't part of the original SIMPLE
| > | grammar.
| > |
| > | As a related change it also allow REALPART_EXPR and IMAGPART_EXPR as
| > | operands of an ADDR_EXPR. Without this &__real__ z would silently
| > | gimplify to the address of a temporary, not the component of the
| > | complex value.
| >
| > Hmm, why would a temporary would be needed if the ref were a array ref?
|
| They aren't array refs, we just apply the same rules when gimplifying.
| The problem is that we allow complex component refs when gimplifying
| compound lvalues, but then reject them when testing if the result is an
| lvalue. In some cases this causes unwanted temporaries, in others an ICE.
Thanks.
-- Gaby