This is the mail archive of the
mailing list for the GCC project.
Re: Some aliasing questions
- From: Richard Biener <rguenther at suse dot de>
- To: Richard Henderson <rth at redhat dot com>,Alan Modra <amodra at gmail dot com>,Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- Cc: gcc at gcc dot gnu dot org,dje dot gcc at gmail dot com
- Date: Tue, 12 Apr 2016 17:50:38 +0200
- 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> <20160412003006 dot GT18129 at bubble dot grove dot modra dot org> <570D1031 dot 90704 at redhat dot com>
On April 12, 2016 5:11:45 PM GMT+02:00, Richard Henderson <email@example.com> wrote:
>On 04/11/2016 05:30 PM, Alan Modra wrote:
>> Either way, when we split to
>> set (reg tmp) (high (const (minus ((symbol_ref) (reg 2)))))
>> .. mem (lo_sum (reg tmp) (const (minus ((symbol_ref) (reg 2)))))
>> both high and lo_sum reference r2 and the linker could happily
>> rtmp in the lo_sum insn with r2 when the high address is known to be
>It would be interesting to see if the r2 reference in fact gets picked
>inside the const. My first reaction is that I could imagine tracking
>over it completely, since we've been promised that the expression is
>Alternately, perhaps alias.c should reuse the existing
>hook, allowing it to look through your current unspecs.
Wouldn't that be quite expensive (building RTL)?