On Thu, Jul 8, 2021 at 7:56 AM Segher Boessenkool
wrote:
>
> On Wed, Jul 07, 2021 at 11:32:59PM +0800, Hongtao Liu wrote:
> > On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
> > wrote:
> > > So, a "FAKE_CALL" is very much a *real* call, on the RTL level, which is
> > > where we are here. But
On Thu, Jul 8, 2021 at 7:44 AM Segher Boessenkool
wrote:
>
> On Wed, Jul 07, 2021 at 11:23:48PM +0800, Hongtao Liu wrote:
> > On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
> > wrote:
>
> [ snip some old stuff ]
>
> > > Yeah. This stuff needs a rethink.
> > >
> > > What is wrong with just us
On Wed, Jul 07, 2021 at 11:32:59PM +0800, Hongtao Liu wrote:
> On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
> wrote:
> > So, a "FAKE_CALL" is very much a *real* call, on the RTL level, which is
> > where we are here. But you want it to be treated differently because it
> > will eventually b
On Wed, Jul 07, 2021 at 11:23:48PM +0800, Hongtao Liu wrote:
> On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
> wrote:
[ snip some old stuff ]
> > Yeah. This stuff needs a rethink.
> >
> > What is wrong with just using an unspec and clobbers?
> >
> It's partial and **potential clobber**,
A
On 7/7/2021 8:55 AM, Segher Boessenkool wrote:
On Mon, Jul 05, 2021 at 06:03:21PM -0600, Jeff Law wrote:
It reminds me a bit of millicode calls on the PA or calls to special
routines in libgcc. They're calls to functions, but those functions do
not follow the standard ABI.
Something with CA
On Wed, Jul 7, 2021 at 4:15 PM Richard Biener
wrote:
>
> On Wed, Jul 7, 2021 at 4:40 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > On Tue, Jul 6, 2021 at 9:37 AM Hongtao Liu wrote:
> > >
> > > On Tue, Jul 6, 2021 at 7:31 AM Segher Boessenkool
> > > wrote:
> > > >
> > > > Hi!
> > > >
> > > > I
On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Wed, Jul 07, 2021 at 10:15:08AM +0200, Richard Biener wrote:
> > On Wed, Jul 7, 2021 at 4:40 AM Hongtao Liu via Gcc-patches
> > wrote:
> > > On Tue, Jul 6, 2021 at 9:37 AM Hongtao Liu wrote:
> > > > On Tue, Jul 6, 2021 at 7
On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Wed, Jul 07, 2021 at 10:15:08AM +0200, Richard Biener wrote:
> > On Wed, Jul 7, 2021 at 4:40 AM Hongtao Liu via Gcc-patches
> > wrote:
> > > On Tue, Jul 6, 2021 at 9:37 AM Hongtao Liu wrote:
> > > > On Tue, Jul 6, 2021 at 7
On Mon, Jul 05, 2021 at 06:03:21PM -0600, Jeff Law wrote:
> It reminds me a bit of millicode calls on the PA or calls to special
> routines in libgcc. They're calls to functions, but those functions do
> not follow the standard ABI.
Something with CALL_INSN_FUNCTION_USAGE? And maybe some clobb
Hi!
On Wed, Jul 07, 2021 at 10:15:08AM +0200, Richard Biener wrote:
> On Wed, Jul 7, 2021 at 4:40 AM Hongtao Liu via Gcc-patches
> wrote:
> > On Tue, Jul 6, 2021 at 9:37 AM Hongtao Liu wrote:
> > > On Tue, Jul 6, 2021 at 7:31 AM Segher Boessenkool
> > > wrote:
> > > > I ran into this in shrink-
On Wed, Jul 7, 2021 at 4:40 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Tue, Jul 6, 2021 at 9:37 AM Hongtao Liu wrote:
> >
> > On Tue, Jul 6, 2021 at 7:31 AM Segher Boessenkool
> > wrote:
> > >
> > > Hi!
> > >
> > > I ran into this in shrink-wrap.c today.
> > >
> > > On Thu, Jun 03, 2021 at 02:
On Tue, Jul 6, 2021 at 9:37 AM Hongtao Liu wrote:
>
> On Tue, Jul 6, 2021 at 7:31 AM Segher Boessenkool
> wrote:
> >
> > Hi!
> >
> > I ran into this in shrink-wrap.c today.
> >
> > On Thu, Jun 03, 2021 at 02:54:07PM +0800, liuhongt via Gcc-patches wrote:
> > > Use "used" flag for CALL_INSN to ind
On Tue, Jul 6, 2021 at 8:03 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 7/5/2021 5:30 PM, Segher Boessenkool wrote:
> > Hi!
> >
> > I ran into this in shrink-wrap.c today.
> >
> > On Thu, Jun 03, 2021 at 02:54:07PM +0800, liuhongt via Gcc-patches wrote:
> >> Use "used" flag for CALL_INSN to indi
On Tue, Jul 6, 2021 at 7:31 AM Segher Boessenkool
wrote:
>
> Hi!
>
> I ran into this in shrink-wrap.c today.
>
> On Thu, Jun 03, 2021 at 02:54:07PM +0800, liuhongt via Gcc-patches wrote:
> > Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a
> > fake call, it won't have its own
On 7/5/2021 5:30 PM, Segher Boessenkool wrote:
Hi!
I ran into this in shrink-wrap.c today.
On Thu, Jun 03, 2021 at 02:54:07PM +0800, liuhongt via Gcc-patches wrote:
Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a
fake call, it won't have its own function stack.
Could
Hi!
I ran into this in shrink-wrap.c today.
On Thu, Jun 03, 2021 at 02:54:07PM +0800, liuhongt via Gcc-patches wrote:
> Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a
> fake call, it won't have its own function stack.
Could you document somewhere what a "fake call" *is*?
On Thu, Jun 03, 2021 at 02:54:07PM +0800, liuhongt wrote:
> Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a
> fake call, it won't have its own function stack.
>
> gcc/ChangeLog
>
> PR target/82735
> * df-scan.c (df_get_call_refs): When call_insn is a fake call,
>
Ping,
This is a splitted middle-end patch as a follow up of
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571544.html
On Thu, Jun 3, 2021 at 2:54 PM liuhongt via Gcc-patches
wrote:
>
> Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a
> fake call, it won't have its own f
Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a
fake call, it won't have its own function stack.
gcc/ChangeLog
PR target/82735
* df-scan.c (df_get_call_refs): When call_insn is a fake call,
it won't use stack pointer reg.
* final.c (leaf_funct
19 matches
Mail list logo
