public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* prevent zero-extension when using a memory load instruction
@ 2020-04-18 15:12 William Tambe
  2020-04-18 15:32 ` Marc Glisse
  2020-04-20  9:50 ` Segher Boessenkool
  0 siblings, 2 replies; 7+ messages in thread
From: William Tambe @ 2020-04-18 15:12 UTC (permalink / raw)
  To: gcc-help

In the machine description file, is there a way to tell GCC that a
memory load instruction already zero-extend such that it does not try
to apply zero-extension ?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: prevent zero-extension when using a memory load instruction
  2020-04-18 15:12 prevent zero-extension when using a memory load instruction William Tambe
@ 2020-04-18 15:32 ` Marc Glisse
  2020-04-18 18:36   ` William Tambe
  2020-04-20  9:50 ` Segher Boessenkool
  1 sibling, 1 reply; 7+ messages in thread
From: Marc Glisse @ 2020-04-18 15:32 UTC (permalink / raw)
  To: William Tambe; +Cc: gcc-help

On Sat, 18 Apr 2020, William Tambe via Gcc-help wrote:

> In the machine description file, is there a way to tell GCC that a
> memory load instruction already zero-extend such that it does not try
> to apply zero-extension ?

I would look at it the other way around: you can tell GCC what asm to 
generate for a zero_extend with a memory operand. Or did you have a 
specific example in mind?

-- 
Marc Glisse

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: prevent zero-extension when using a memory load instruction
  2020-04-18 15:32 ` Marc Glisse
@ 2020-04-18 18:36   ` William Tambe
  2020-04-18 18:45     ` Jeff Law
  0 siblings, 1 reply; 7+ messages in thread
From: William Tambe @ 2020-04-18 18:36 UTC (permalink / raw)
  To: gcc-help

On Sat, Apr 18, 2020 at 11:32 AM Marc Glisse <marc.glisse@inria.fr> wrote:
>
> On Sat, 18 Apr 2020, William Tambe via Gcc-help wrote:
>
> > In the machine description file, is there a way to tell GCC that a
> > memory load instruction already zero-extend such that it does not try
> > to apply zero-extension ?
>
> I would look at it the other way around: you can tell GCC what asm to
> generate for a zero_extend with a memory operand. Or did you have a

Thanks; tried above, but GCC still prefer a memory load followed by
zero-extension.

The example code used is as follow:

    unsigned char var;
    int main() {
        return var;
    }

Also tried x86 and ARM GCC port to see what they produce, and find
that only x86 will not generate a zero-extension when -Os is used.

The version of GCC used is 9.2.0.

Any other suggestions on how to tell GCC not to zero-extend the result
of a memory load ?

> specific example in mind?
>
> --
> Marc Glisse

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: prevent zero-extension when using a memory load instruction
  2020-04-18 18:36   ` William Tambe
@ 2020-04-18 18:45     ` Jeff Law
  0 siblings, 0 replies; 7+ messages in thread
From: Jeff Law @ 2020-04-18 18:45 UTC (permalink / raw)
  To: William Tambe, gcc-help

On Sat, 2020-04-18 at 14:36 -0400, William Tambe via Gcc-help wrote:
> On Sat, Apr 18, 2020 at 11:32 AM Marc Glisse <marc.glisse@inria.fr> wrote:
> > On Sat, 18 Apr 2020, William Tambe via Gcc-help wrote:
> > 
> > > In the machine description file, is there a way to tell GCC that a
> > > memory load instruction already zero-extend such that it does not try
> > > to apply zero-extension ?
> > 
> > I would look at it the other way around: you can tell GCC what asm to
> > generate for a zero_extend with a memory operand. Or did you have a
> 
> Thanks; tried above, but GCC still prefer a memory load followed by
> zero-extension.
> 
> The example code used is as follow:
> 
>     unsigned char var;
>     int main() {
>         return var;
>     }
> 
> Also tried x86 and ARM GCC port to see what they produce, and find
> that only x86 will not generate a zero-extension when -Os is used.
> 
> The version of GCC used is 9.2.0.
> 
> Any other suggestions on how to tell GCC not to zero-extend the result
> of a memory load ?
Many ports have this feature and it's discussed in the developer documentation. 
Please read it.

jeff


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: prevent zero-extension when using a memory load instruction
  2020-04-18 15:12 prevent zero-extension when using a memory load instruction William Tambe
  2020-04-18 15:32 ` Marc Glisse
@ 2020-04-20  9:50 ` Segher Boessenkool
  2020-04-20 14:36   ` William Tambe
  1 sibling, 1 reply; 7+ messages in thread
From: Segher Boessenkool @ 2020-04-20  9:50 UTC (permalink / raw)
  To: William Tambe; +Cc: gcc-help

Hi!

On Sat, Apr 18, 2020 at 11:12:15AM -0400, William Tambe via Gcc-help wrote:
> In the machine description file, is there a way to tell GCC that a
> memory load instruction already zero-extend such that it does not try
> to apply zero-extension ?

At least on a load-store architecture (like a usual RISC), you get best
results if you make a separate pattern for that, and then let combine
combine the zero_extend with the load.


Segher

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: prevent zero-extension when using a memory load instruction
  2020-04-20  9:50 ` Segher Boessenkool
@ 2020-04-20 14:36   ` William Tambe
  2020-04-20 15:47     ` Segher Boessenkool
  0 siblings, 1 reply; 7+ messages in thread
From: William Tambe @ 2020-04-20 14:36 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: gcc-help

On Mon, Apr 20, 2020 at 5:50 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Sat, Apr 18, 2020 at 11:12:15AM -0400, William Tambe via Gcc-help wrote:
> > In the machine description file, is there a way to tell GCC that a
> > memory load instruction already zero-extend such that it does not try
> > to apply zero-extension ?
>
> At least on a load-store architecture (like a usual RISC), you get best
> results if you make a separate pattern for that, and then let combine
> combine the zero_extend with the load.

I tried creating zero_extend pattern that could move data from memory
to a register (aka memory load), however GCC never used it and
preferred using memory load followed by a zero-extend.

Any other suggestions ? I have been googling around with no solution in sight.

>
>
> Segher

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: prevent zero-extension when using a memory load instruction
  2020-04-20 14:36   ` William Tambe
@ 2020-04-20 15:47     ` Segher Boessenkool
  0 siblings, 0 replies; 7+ messages in thread
From: Segher Boessenkool @ 2020-04-20 15:47 UTC (permalink / raw)
  To: William Tambe; +Cc: gcc-help

Hi!

On Mon, Apr 20, 2020 at 10:36:35AM -0400, William Tambe via Gcc-help wrote:
> > > In the machine description file, is there a way to tell GCC that a
> > > memory load instruction already zero-extend such that it does not try
> > > to apply zero-extension ?
> >
> > At least on a load-store architecture (like a usual RISC), you get best
> > results if you make a separate pattern for that, and then let combine
> > combine the zero_extend with the load.
> 
> I tried creating zero_extend pattern that could move data from memory
> to a register (aka memory load), however GCC never used it and
> preferred using memory load followed by a zero-extend.

Use -dap and look at the dump files; see what happened?  You often get
it done by expand already (which isn't such a great idea, but hey), but
some cases are done by combine as well.  If you get separate load and
extend insns generated, you can look at the combine dump to see why
those insns didn't combine there.


Segher

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-04-20 15:47 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-18 15:12 prevent zero-extension when using a memory load instruction William Tambe
2020-04-18 15:32 ` Marc Glisse
2020-04-18 18:36   ` William Tambe
2020-04-18 18:45     ` Jeff Law
2020-04-20  9:50 ` Segher Boessenkool
2020-04-20 14:36   ` William Tambe
2020-04-20 15:47     ` Segher Boessenkool

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).