On Fri, Feb 19, 2016 at 01:42:20PM +0100, Richard Biener wrote:
> On Fri, 19 Feb 2016, Bernd Schmidt wrote:
>
> > On 02/19/2016 09:36 AM, Richard Biener wrote:
> > > Yup, so we should make sure we don't (even not "out of nowhere"). See
> > > my attempts on adding some SSA verification for this (n
On Fri, 19 Feb 2016, Bernd Schmidt wrote:
> On 02/19/2016 09:36 AM, Richard Biener wrote:
> > Yup, so we should make sure we don't (even not "out of nowhere"). See
> > my attempts on adding some SSA verification for this (needs to be
> > restricted to overaligned, then it doesn't trigger that oft
On 02/19/2016 09:36 AM, Richard Biener wrote:
Yup, so we should make sure we don't (even not "out of nowhere"). See
my attempts on adding some SSA verification for this (needs to be
restricted to overaligned, then it doesn't trigger that often...).
One issue is that we've often got DECLs that ar
On Fri, 19 Feb 2016, Eric Botcazou wrote:
> > So you simply assume that exp_type is naturally aligned here. I think
> > you should test align < TYPE_ALIGN (TYPE_MAIN_VARIANT (exp_type)) here,
> > no?
>
> No strong opinion, but the patch is only intended to mitigate the effects of
> the PR65310
> So you simply assume that exp_type is naturally aligned here. I think
> you should test align < TYPE_ALIGN (TYPE_MAIN_VARIANT (exp_type)) here,
> no?
No strong opinion, but the patch is only intended to mitigate the effects of
the PR65310 one-liner, including on the 5 branch, so it's minimal.
On Sun, 14 Feb 2016, Eric Botcazou wrote:
> > No, but if there is none left why would you want to "fix" SRA?
>
> As expected, it seems that the make_ssa_name_fn kludge is not sufficient, so
> I'm proposing to disable the PR65310 one-liner for selected targets, using
> the
> function_arg_bounda
> No, it is a major deficiency in the backends.
Back-ends were obviously written with the natural alignment of types in mind
and were not prepared for overaligned non-aggregate types. Fixing MIPS will
not fix the other dozen and one can wonder, as was already mentioned by a few
other people, w
On Sun, Feb 14, 2016 at 10:35:17PM +0100, Eric Botcazou wrote:
> > How does that help? Testcases have been posted multiple times that show
> > that if targets look at type alignment of non-aggregate types, they have
> > just broken argument passing, so conditionally reverting the tree-sra
> > impr
> How does that help? Testcases have been posted multiple times that show
> that if targets look at type alignment of non-aggregate types, they have
> just broken argument passing, so conditionally reverting the tree-sra
> improvements can't help.
Well, that has been the case for 2 decades for so
On Sun, Feb 14, 2016 at 09:39:56PM +0100, Eric Botcazou wrote:
> > No, but if there is none left why would you want to "fix" SRA?
>
> As expected, it seems that the make_ssa_name_fn kludge is not sufficient, so
> I'm proposing to disable the PR65310 one-liner for selected targets, using
> the
>
> No, but if there is none left why would you want to "fix" SRA?
As expected, it seems that the make_ssa_name_fn kludge is not sufficient, so
I'm proposing to disable the PR65310 one-liner for selected targets, using the
function_arg_boundary hook, until after we have a clear way out of this mes
On February 8, 2016 5:31:16 PM GMT+01:00, Eric Botcazou
wrote:
>> No, but if there is none left why would you want to "fix" SRA?
>
>Because I'm afraid this over-aligned type might leak into other places
>so we
>would probably be better off not creating it in the first place, all
>the more
>so t
> No, but if there is none left why would you want to "fix" SRA?
Because I'm afraid this over-aligned type might leak into other places so we
would probably be better off not creating it in the first place, all the more
so that it is probably useless in most cases.
For PR tree-opt/65310, why co
On Mon, 8 Feb 2016, Eric Botcazou wrote:
> > Yes, that place I just fixed. I mean for the SRA case.
>
> Are you sure that there is one?
No, but if there is none left why would you want to "fix" SRA?
Richard.
> expr = build_ref_for_model (loc, agg, access->offset - top_offset,
>
> Yes, that place I just fixed. I mean for the SRA case.
Are you sure that there is one?
expr = build_ref_for_model (loc, agg, access->offset - top_offset,
access, gsi, insert_after);
if (write)
{
if (access->gr
On Mon, 8 Feb 2016, Eric Botcazou wrote:
> > Not sure what to make of this comment ;)
>
> I guess it was a variant of the usual can-of-worms-opening thing. :-)
>
> > Did you see where we create the SSA name with the overaligned type?
>
> In tree-ssa-pre.c:insert_into_preds_of_block:
>
> (gdb)
> Not sure what to make of this comment ;)
I guess it was a variant of the usual can-of-worms-opening thing. :-)
> Did you see where we create the SSA name with the overaligned type?
In tree-ssa-pre.c:insert_into_preds_of_block:
(gdb) p debug_pre_expr(expr)
{mem_ref<0B>,yyvsp_1}@.MEM_2
(gdb) p
On Mon, 8 Feb 2016, Eric Botcazou wrote:
> > It helps vectorization. This was specifically introduced to fix a
> > regression on powerpc.
> >
> > See PR65310.
>
> Indeed, the SRA code was much better before that one liner. ;-)
Not sure what to make of this comment ;) Did you see where we
crea
> It helps vectorization. This was specifically introduced to fix a
> regression on powerpc.
>
> See PR65310.
Indeed, the SRA code was much better before that one liner. ;-)
--
Eric Botcazou
On Mon, 8 Feb 2016, Eric Botcazou wrote:
> > No, that's not over-aliging a salar type, that's preserving alignment
> > information on the memory reference.
>
> What would we lose exactly by lowering the alignment to that of the type?
> What's the point in knowing that a 32-bit integer is 64-bit a
> No, that's not over-aliging a salar type, that's preserving alignment
> information on the memory reference.
What would we lose exactly by lowering the alignment to that of the type?
What's the point in knowing that a 32-bit integer is 64-bit aligned at the
GIMPLE level?
--
Eric Botcazou
On Mon, 8 Feb 2016, Eric Botcazou wrote:
> > This makes it less likely (for example through the PRE path) to trigger
> > target bugs like PR68273 where targets use type alignment of call
> > arguments to decide on the ABI.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to tr
> This makes it less likely (for example through the PRE path) to trigger
> target bugs like PR68273 where targets use type alignment of call
> arguments to decide on the ABI.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Thanks. I think that we can also avoid this i
This makes it less likely (for example through the PRE path) to trigger
target bugs like PR68273 where targets use type alignment of call
arguments to decide on the ABI.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
IMHO targets should still be fixed.
Richard.
2016-02-
24 matches
Mail list logo
