> It seems to me that the issue in the end is that where we compute
> alignment from is the pieces gathered by get_inner_reference
> instead of computing it alongside of that information in
> get_inner_reference, taking advantage of DECL_OFFSET_ALIGN
> and the array element type alignment there. T
On Mon, 2 May 2016, Eric Botcazou wrote:
> > The following experiment resulted from looking at making
> > array_ref_low_bound and array_ref_element_size non-mutating. Again
> > I wondered why we do this strange scaling by offset/element alignment.
>
> The idea is to expose the alignment factor t
> The following experiment resulted from looking at making
> array_ref_low_bound and array_ref_element_size non-mutating. Again
> I wondered why we do this strange scaling by offset/element alignment.
The idea is to expose the alignment factor to the RTL expander:
tree tem
= ge
> Did you manage to do this yet? I'm flushing my stage1 queue of
> "simple cleanups" right now.
No, I'm going to have a look this week.
--
Eric Botcazou
On Fri, Feb 19, 2016 at 9:33 AM, Eric Botcazou wrote:
>> The following experiment resulted from looking at making
>> array_ref_low_bound and array_ref_element_size non-mutating. Again
>> I wondered why we do this strange scaling by offset/element alignment.
>
> I personally never really grasped i
> The following experiment resulted from looking at making
> array_ref_low_bound and array_ref_element_size non-mutating. Again
> I wondered why we do this strange scaling by offset/element alignment.
I personally never really grasped it either...
> So - I hope somebody from Adacore can evaluate
The following experiment resulted from looking at making
array_ref_low_bound and array_ref_element_size non-mutating. Again
I wondered why we do this strange scaling by offset/element alignment.
This exposes sth to GIMPLE (the division) that is in the end not
necessary while costing extra tree
