This is the mail archive of the 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: [PATCH][mem-ref] Re-enable IVOPTs, build MEM_REF instead of TARGET_MEM_REF (help!)

On Sun, 9 Mar 2008, Zdenek Dvorak wrote:

> Hi,
> > if I tell it that I don't like this I get the same index with integer
> > type in addr->base.
> > 
> > Ugh.  Zdenek, can you help me here?  Why does it even start with
> > this index-only address info?
> no idea, it looks like a bug; certainly the address should have pointer
> type.

Yep, see the followup.

> Btw. for record, I do not like the idea of replacing the TARGET_MEM_REFs
> with MEM_REF+IDX_EXPRs.  The purpose of MEM_REF+IDX_EXPRs IMHO should be to
> describe high-level structured addressing (arrays with indices).  Mixing
> different things together and using it to describe low-level
> target-specific addressing modes as well makes me worried, as that
> means that the semantics of IDX_EXPRs before and after ivopts changes
> subtly -- before ivopts (or certainly, before any pass that uses dependency
> analysis), we need them to faithfully describe indices of the arrays,
> after ivopts, we suddenly start to use them for arbitrary accesses.

Array-like accesses, but yes at the moment they are only generated if
at lowering time there was an ARRAY_REF.

I have no strong opinion here, but TARGET_MEM_REF looked redundant
to me in the face of MEM_REF + IDX_EXPR.  We can decide what to do
after some experiments.

> Also, using the combination of MEM_REFs/IDX_EXPRs seems not to ensure
> that we will use the addressing mode selected by ivopts, basically
> reverting us to the state before introducing TARGET_MEM_REFs.  For
> example, I guess that for this code
> int a[100];
> for (i = 0; i < 100; i++)
>   a[i] = b[i];
> We will produce
> int i;
> for (i = 0; i < 100; i++)
>   {
>     offset = idx (4 * i);
>     mem_ref (a, offset) = mem_ref(b, offset);
>   }
> and we will get an unnecessary multiplication by 4 after tree->rtl
> expansion.

IVOPTs will create two (but same) IDX_EXPRs, so unless we run CSE
after IVOPTs again TER should be able to combine these with the
MEM_REFs again.  But it was designed to work with expansion from
SSA in mind.


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