Hi,
On Tue, 16 Apr 2019, Jeff Law wrote:
> So going back to Jakub's patch... I think the discussion points to
> avoiding the REG_EQUIV notes for outgoing argument slots.
In the long run definitely, but maybe his current solution is more
amenable to stage 4, no idea.
Ciao,
Michael.
On 4/16/19 9:35 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 16 Apr 2019, Jeff Law wrote:
>
>>> I still don't think that what you want follows. Imagine this:
>>>
>>> int foo (int i) { ++i; return i; }
>>>
>>> To claim that this function is anything else than const+pure seems weird
>>> (in fact
Hi,
On Tue, 16 Apr 2019, Jeff Law wrote:
> > I still don't think that what you want follows. Imagine this:
> >
> > int foo (int i) { ++i; return i; }
> >
> > To claim that this function is anything else than const+pure seems weird
> > (in fact this function doesn't access anything that
On 4/15/19 6:51 AM, Michael Matz wrote:
> Hi,
>
> On Fri, 12 Apr 2019, Jeff Law wrote:
>
>>> I don't think this follows. Imagine a pure foo tailcalling a pure bar.
>>> To make the tailcall, foo may need to change some of its argument slots
>>> to pass new arguments to bar.
>> I'd claim that a
Hi,
On Fri, 12 Apr 2019, Jeff Law wrote:
> > I don't think this follows. Imagine a pure foo tailcalling a pure bar.
> > To make the tailcall, foo may need to change some of its argument slots
> > to pass new arguments to bar.
> I'd claim that a pure/const call can't tail call another function as
On 4/11/19 3:04 AM, Jakub Jelinek wrote:
> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>>
>>> During those 2 bootstraps/regtests, data.load_found has been set just
>>> on the new testcase on ia32.
>>
>>
On 4/11/19 3:26 AM, Richard Biener wrote:
> On Thu, 11 Apr 2019, Jakub Jelinek wrote:
>
>> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
During those 2 bootstraps/regtests, data.load_found has
On 4/12/19 9:32 AM, Alexander Monakov wrote:
> On Fri, 12 Apr 2019, Jeff Law wrote:
>> We've been through the "who owns the argument slots, caller or callee"
>> discussion a few times and I don't think we've ever reached any kind of
>> conclusion in the general case.
>
> Callee must own the slots
On Fri, 12 Apr 2019, Jeff Law wrote:
> We've been through the "who owns the argument slots, caller or callee"
> discussion a few times and I don't think we've ever reached any kind of
> conclusion in the general case.
Callee must own the slots for tail calls to be possible.
> I think this case
On 4/11/19 1:54 AM, Richard Biener wrote:
> On Thu, 11 Apr 2019, Jakub Jelinek wrote:
>
>> Hi!
>>
>> The following testcase is miscompiled, because the result of
>> a DImode (doubleword) right shift is used in a QImode subreg as well as
>> later on pushed into a stack slot as an argument to a
On Thu, 11 Apr 2019, Jakub Jelinek wrote:
> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > >
> > > During those 2 bootstraps/regtests, data.load_found has been set just
> > > on the new testcase on
On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > During those 2 bootstraps/regtests, data.load_found has been set just
> > on the new testcase on ia32.
>
> Hmm, I wonder whether we really need to DCE
On Thu, 11 Apr 2019, Jakub Jelinek wrote:
> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
> > > The following patch just punts if we find loads from stack slots in
> > > between
> > > where they are pushed and the const/pure call. In addition to that, I've
> > > outlined the
On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
> > The following patch just punts if we find loads from stack slots in between
> > where they are pushed and the const/pure call. In addition to that, I've
> > outlined the same largish sequence that had 3 copies in the function
On Thu, 11 Apr 2019, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because the result of
> a DImode (doubleword) right shift is used in a QImode subreg as well as
> later on pushed into a stack slot as an argument to a const function
> whose result isn't used. The RA
Hi!
The following testcase is miscompiled, because the result of
a DImode (doubleword) right shift is used in a QImode subreg as well as
later on pushed into a stack slot as an argument to a const function
whose result isn't used. The RA because of the weirdo target tuning
reuses the REG_EQUIV
16 matches
Mail list logo
