This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Some aliasing questions
- From: Richard Henderson <rth at redhat dot com>
- To: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>, gcc at gcc dot gnu dot org
- Cc: dje dot gcc at gmail dot com, rguenther at suse dot de
- Date: Fri, 8 Apr 2016 13:41:05 -0700
- 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>
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.
> (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.
r~