On Tue, Oct 9, 2018 at 1:53 PM Joseph Myers wrote:
>
> On Tue, 9 Oct 2018, Richard Biener wrote:
>
> > It was repeatedly suggested that we _could_ derive alignment info from
> > function parameter types since we rely on precise typing there for example
> > for points-to analysis (albeit only for r
On Tue, 9 Oct 2018, Richard Biener wrote:
> It was repeatedly suggested that we _could_ derive alignment info from
> function parameter types since we rely on precise typing there for example
> for points-to analysis (albeit only for restrict qualification processing and
> for DECL_BY_REFERENCE "p
On Tue, Oct 9, 2018 at 11:23 AM Jakub Jelinek wrote:
>
> On Tue, Oct 09, 2018 at 11:08:44AM +0200, Richard Biener wrote:
> > On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov
> > wrote:
> > >
> > > On Tue, 9 Oct 2018, Richard Biener wrote:
> > > >
> > > > then we cannot set the alignment of i_1
On Tue, Oct 09, 2018 at 11:08:44AM +0200, Richard Biener wrote:
> On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov wrote:
> >
> > On Tue, 9 Oct 2018, Richard Biener wrote:
> > >
> > > then we cannot set the alignment of i_1 at/after k = *i_1 because doing
> > > so would
> > > affect the alignmen
On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov wrote:
>
> On Tue, 9 Oct 2018, Richard Biener wrote:
> >
> > then we cannot set the alignment of i_1 at/after k = *i_1 because doing so
> > would
> > affect the alignment test which we'd then optimize away. We'd need to
> > introduce
> > a SSA c
On Tue, 9 Oct 2018, Richard Biener wrote:
>
> then we cannot set the alignment of i_1 at/after k = *i_1 because doing so
> would
> affect the alignment test which we'd then optimize away. We'd need to
> introduce
> a SSA copy to get a new SSA name but that would be optimized away quickly.
We p
> It was repeatedly suggested that we _could_ derive alignment info from
> function parameter types since we rely on precise typing there for example
> for points-to analysis (albeit only for restrict qualification processing
> and for DECL_BY_REFERENCE "pointers"). That would fix the simple testc
On Tue, Oct 9, 2018 at 10:02 AM Andrew Haley wrote:
>
> On 10/08/2018 07:38 PM, Paul Koning wrote:
> >
> >
> >> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
> >>
> >> On 10/08/2018 06:20 PM, Michael Matz wrote:
> >>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>
On Tue, Oct 9, 2018 at 8:41 AM Eric Botcazou wrote:
>
> > It's not quite obvious what SSE has to do with this - any hint please?
>
> SSE introduced alignment constraints into the non-strict-alignment target x86
> so people didn't really want to play by the rules of strict-alignment targets.
Yeah.
On 10/08/2018 07:38 PM, Paul Koning wrote:
>
>
>> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
>>
>> On 10/08/2018 06:20 PM, Michael Matz wrote:
>>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>>> only have the "accesses" via memcpy, and as Richi says, those do
> It's not quite obvious what SSE has to do with this - any hint please?
SSE introduced alignment constraints into the non-strict-alignment target x86
so people didn't really want to play by the rules of strict-alignment targets.
> (according to my quick check this changed between gcc-4.5 and gc
On Tue, 9 Oct 2018, Richard Biener wrote:
> >This had worked as Paul expects until GCC 4.4 IIRC and this was perfectly OK
> >for every language on strict-alignment platforms. This was changed only
> >because of SSE on x86.
>
> And because we ended up ignoring all pointer casts.
It's not quite o
On October 8, 2018 11:43:00 PM GMT+02:00, Eric Botcazou
wrote:
>> That's correct, I was explaining from the middle-end perspective.
>There
>> we are consciously more lenient as we have to support the real world
>and
>> other languages than C. This is one of the cases.
>
>This had worked as Paul
> On Oct 8, 2018, at 5:43 PM, Eric Botcazou wrote:
>
>> That's correct, I was explaining from the middle-end perspective. There
>> we are consciously more lenient as we have to support the real world and
>> other languages than C. This is one of the cases.
>
> This had worked as Paul expect
> That's correct, I was explaining from the middle-end perspective. There
> we are consciously more lenient as we have to support the real world and
> other languages than C. This is one of the cases.
This had worked as Paul expects until GCC 4.4 IIRC and this was perfectly OK
for every languag
Hi,
On Mon, 8 Oct 2018, Paul Koning wrote:
> > So all you'd actually have to say is
> >
> > void f1(void)
> > {
> >*i; *j;
> >__builtin_memcpy (i, j, 32);
> > }
>
> No, that doesn't help. Not even if I make it:
>
> void f1(void)
> {
> k = *i + *j;
> __builtin_memcpy (i, j, 4);
> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
>
> On 10/08/2018 06:20 PM, Michael Matz wrote:
>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>> only have the "accesses" via memcpy, and as Richi says, those don't imply
>> any alignment requirements. The i a
Hi,
On Mon, 8 Oct 2018, Alexander Monakov wrote:
> > Only if you somewhere visibly add accesses to *i and *j. Without them
> > you only have the "accesses" via memcpy, and as Richi says, those
> > don't imply any alignment requirements. The i and j pointers might
> > validly be char* pointer
On 10/08/2018 06:20 PM, Michael Matz wrote:
> Only if you somewhere visibly add accesses to *i and *j. Without them you
> only have the "accesses" via memcpy, and as Richi says, those don't imply
> any alignment requirements. The i and j pointers might validly be char*
> pointers in disguise a
On Mon, 8 Oct 2018, Michael Matz wrote:
> > Ok, but why is that not a bug? The whole point of passing alignment to
> > the movmem pattern is to let it generate code that takes advantage of
> > the alignment. So we get a missed optimization.
>
> Only if you somewhere visibly add accesses to *i
Hi,
On Mon, 8 Oct 2018, Paul Koning wrote:
> >> extern int *i, *j;
> >> extern int iv[40], jv[40];
> >>
> >> void f1(void)
> >> {
> >>__builtin_memcpy (i, j, 32);
> >> }
> >>
> >> void f2(void)
> >> {
> >>__builtin_memcpy (iv, jv, 32);
> >> }
> >
> > Yes, memcpy doesn't require anythin
> On Oct 8, 2018, at 11:09 AM, Richard Biener
> wrote:
>
> On Mon, Oct 8, 2018 at 3:57 PM Paul Koning wrote:
>>
>> I have a movmem pattern in my target that pays attention to the alignment
>> argument.
>>
>> GCC isn't passing in the expected alignment part of the time. I have this
>> te
On Mon, Oct 8, 2018 at 3:57 PM Paul Koning wrote:
>
> I have a movmem pattern in my target that pays attention to the alignment
> argument.
>
> GCC isn't passing in the expected alignment part of the time. I have this
> test case:
>
> extern int *i, *j;
> extern int iv[40], jv[40];
>
> void f1(
I have a movmem pattern in my target that pays attention to the alignment
argument.
GCC isn't passing in the expected alignment part of the time. I have this test
case:
extern int *i, *j;
extern int iv[40], jv[40];
void f1(void)
{
__builtin_memcpy (i, j, 32);
}
void f2(void)
{
__buil
24 matches
Mail list logo
