This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Some aliasing questions
- From: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, dje dot gcc at gmail dot com, rguenther at suse dot de
- Date: Fri, 08 Apr 2016 16:41:13 -0500
- Subject: Re: Some aliasing questions
- Authentication-results: sourceware.org; auth=none
- References: <1460139016 dot 18355 dot 36 dot camel at oc8801110288 dot ibm dot com> <57081761 dot 8040502 at redhat dot com>
On Fri, 2016-04-08 at 13:41 -0700, Richard Henderson wrote:
> On 04/08/2016 11:10 AM, Bill Schmidt wrote:
> > The first is an issue with TOC-relative addresses on PowerPC. These are
> > symbolic addresses that are to be loaded from a fixed slot in the table
> > of contents, as addressed by the TOC pointer (r2). In the RTL phases
> > prior to register allocation, these are described in an UNSPEC that
> > looks like this for an example store:
> >
> > (set (mem/c:DI (unspec:DI [
> > (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> > (reg:DI 2 2)
> > ] UNSPEC_TOCREL) [1 svul+0 S8 A128])
> > (reg:DI 178))
> >
> > The UNSPEC helps keep track of the r2 reference until this is split into
> > two or more insns depending on the memory model.
>
>
> That's why Alpha uses LO_SUM for pre-reload tracking of such things.
>
> Even though that's a bit of a liberty, since there's no HIGH to go along with
> the LO_SUM. But at least it allows the middle-end to continue to find the symbol.
Yes, that seems like a better way to handle this. I'll put this on the
to-do list for GCC 7. The fewer UNSPECs the better; ironically, I ran
into this while trying to remove some other UNSPECs...
>
> > (1) What is the best way to handle this? Would it be better to have
> > some sort of target hook?
>
> Perhaps, yes.
>
> > Another issue I see involves disjoint alias sets. If you look closely
> > at the rtx's above, they have been marked as disjoint, belonging to
> > alias sets 1 and 4, respectively:
> ...
> > _11 = (__vector unsigned long *) _10;
> ...
> > static unsigned long long svul[2] __attribute__ ((aligned (16)));
>
> Be consistent about unsigned long vs unsigned long long and this will be fixed.
Right -- we have some history here with these built-ins and their
signatures, which should have been designed to use long long all the
time to avoid inconsistencies between 32-bit and 64-bit targets.
Because long and long long are essentially synonyms on ppc64, I'm a bit
blind to spotting these situations. I think I will have to use
may-alias types for these during the expansion, as Richi suggested.
Thanks to both of you for the help!
Bill
>
>
> r~
>