public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* SUBREGs and modes
@ 2000-08-02  5:49 Jan Hubicka
  2000-08-02  5:58 ` Jakub Jelinek
  2000-08-02  8:39 ` Joern Rennecke
  0 siblings, 2 replies; 7+ messages in thread
From: Jan Hubicka @ 2000-08-02  5:49 UTC (permalink / raw)
  To: gcc; +Cc: jakub

Hi
(except for many other cases), my checker pointed out
weird usage of SUBREGs. According to my uderstanding the docs, when
WORDNUM is nonzero, the  innermode must be greater than word and
the outer mode must be word.

My checker has caught occurences of subregs not matching these constraints
such as:
(subreg:HI (reg:DI ) 1)
in i386.

These happends in early stages of RTL generation and seems to be results of
combining two SUBREGS together. Simplifiers in recog.c and combine.c can't deal
with such SUBREGS when they get constant insode so we at least miss
optimizations.

So the question is, whether are such subregs correct, if so we
should probably docuemnt their semantics and add optimizations, if not,
how to avoid these?

Jakub: Does your (and Davids) SUBREG_BYTE work touch this issue somehow?

Honza

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

* Re: SUBREGs and modes
  2000-08-02  5:49 SUBREGs and modes Jan Hubicka
@ 2000-08-02  5:58 ` Jakub Jelinek
  2000-08-02  8:39 ` Joern Rennecke
  1 sibling, 0 replies; 7+ messages in thread
From: Jakub Jelinek @ 2000-08-02  5:58 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc

On Wed, Aug 02, 2000 at 02:49:16PM +0200, Jan Hubicka wrote:
> Hi
> (except for many other cases), my checker pointed out
> weird usage of SUBREGs. According to my uderstanding the docs, when
> WORDNUM is nonzero, the  innermode must be greater than word and
> the outer mode must be word.
> 
> My checker has caught occurences of subregs not matching these constraints
> such as:
> (subreg:HI (reg:DI ) 1)
> in i386.
> 
> These happends in early stages of RTL generation and seems to be results of
> combining two SUBREGS together. Simplifiers in recog.c and combine.c can't deal
> with such SUBREGS when they get constant insode so we at least miss
> optimizations.
> 
> So the question is, whether are such subregs correct, if so we
> should probably docuemnt their semantics and add optimizations, if not,
> how to avoid these?
> 
> Jakub: Does your (and Davids) SUBREG_BYTE work touch this issue somehow?

Yes, things are quite different.
First of all, one big endian subreg_lowpart_p has nonzero BYTENUM.
(subreg:QI (reg:SI %eax) 1) is legal e.g. on i386, that's %ah.
I hope SUBREG_BYTE will be integrated soon and thus am not sure how much is
it worth of regoing the SUBREG_WORD stuff now (it would definitely be much
more work for me to keep up with the patches).

	Jakub

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

* Re: SUBREGs and modes
  2000-08-02  5:49 SUBREGs and modes Jan Hubicka
  2000-08-02  5:58 ` Jakub Jelinek
@ 2000-08-02  8:39 ` Joern Rennecke
  2000-08-02  8:49   ` Jan Hubicka
  1 sibling, 1 reply; 7+ messages in thread
From: Joern Rennecke @ 2000-08-02  8:39 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc, jakub

> weird usage of SUBREGs. According to my uderstanding the docs, when
> WORDNUM is nonzero, the  innermode must be greater than word and
> the outer mode must be word.

Where does it say that the outer mode must be word?

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

* Re: SUBREGs and modes
  2000-08-02  8:39 ` Joern Rennecke
@ 2000-08-02  8:49   ` Jan Hubicka
  2000-08-02  9:13     ` Joern Rennecke
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Hubicka @ 2000-08-02  8:49 UTC (permalink / raw)
  To: Joern Rennecke; +Cc: gcc

> > weird usage of SUBREGs. According to my uderstanding the docs, when
> > WORDNUM is nonzero, the  innermode must be greater than word and
> > the outer mode must be word.
> 
> Where does it say that the outer mode must be word?
The other use of @code{subreg} is to extract the individual registers of
a multi-register value.  Machine modes such as @code{DImode} and
@code{TImode} can indicate values longer than a word, values which
usually require two or more consecutive registers.  To access one of the
registers, use a @code{subreg} with mode @code{SImode} and a
@var{wordnum} that says which register. 

Actually speaks about SImode, but is interpreted in the code as
word.

Honza

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

* Re: SUBREGs and modes
  2000-08-02  8:49   ` Jan Hubicka
@ 2000-08-02  9:13     ` Joern Rennecke
  2000-08-02  9:30       ` Jan Hubicka
  0 siblings, 1 reply; 7+ messages in thread
From: Joern Rennecke @ 2000-08-02  9:13 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Joern Rennecke, gcc

> > > weird usage of SUBREGs. According to my uderstanding the docs, when
> > > WORDNUM is nonzero, the  innermode must be greater than word and
> > > the outer mode must be word.
> > 
> > Where does it say that the outer mode must be word?
> The other use of @code{subreg} is to extract the individual registers of
> a multi-register value.  Machine modes such as @code{DImode} and
> @code{TImode} can indicate values longer than a word, values which
> usually require two or more consecutive registers.  To access one of the
> registers, use a @code{subreg} with mode @code{SImode} and a
> @var{wordnum} that says which register. 
> 
> Actually speaks about SImode, but is interpreted in the code as
> word.

Well, this is not a definition, but (a part of) an enumeration of uses.
A subreg can fulfill both uses at a time.
Actually, the very next paragraph hints at that:

Storing in a non-paradoxical @code{subreg} has undefined results for
bits belonging to the same word as the @code{subreg}.  This laxity makes
it easier to generate efficient code for such instructions.  To
represent an instruction that preserves all the bits outside of those in

This implies that there are cases where you have a subreg of a reg with
multiple words, where not all bits of a word are stored to.

Note that nested subregs are not allowed, so we really *have* to express
the access of a single smaller-than-word part of a multi word register
with a single SUBREG.

Do you have a suggestion how to make the documentation more clear on that
count?

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

* Re: SUBREGs and modes
  2000-08-02  9:13     ` Joern Rennecke
@ 2000-08-02  9:30       ` Jan Hubicka
  2000-08-02 12:40         ` Geoff Keating
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Hubicka @ 2000-08-02  9:30 UTC (permalink / raw)
  To: Joern Rennecke; +Cc: Jan Hubicka, Joern Rennecke, gcc

> This implies that there are cases where you have a subreg of a reg with
> multiple words, where not all bits of a word are stored to.
Note that this is not quite an case I am talking about.  My case
(subreg:HI (reg:DI) 1)
is not paradoxical (at least in the definition of word paradoxical I understand
to)
> 
> Note that nested subregs are not allowed, so we really *have* to express
> the access of a single smaller-than-word part of a multi word register
> with a single SUBREG.
I know, thats why I am asking - otherwise I would send patch killing them.
> 
> Do you have a suggestion how to make the documentation more clear on that
> count?
Don't know - perhaps it would be better to wait for the SUBREG_BYTE patches.
The prbolem I am having is that we prohibit SUBREGs of const_int s lurking
around the RTL stream and currently gcse is creating them, since it fails
to simplify the SUBREGs of constants substitued to registers with
NON-SImode and WORDNUM nonzero. This also disables any const propagation on these
beast too - in the CSE, gcse and combine :(

So I am asking basically whether:
1) it is better to keep this issue and wait for SUBREG_BYTE
2) update documentation and make cse/gcse/combine to handle them
3) avoid the (this is impossible)

I will probably pick 2) since otherwise my checker will cry (I am having function
to check corectness of rtx expression and trying to prevent gcc from creating
incorrect ones)
If you have some ideas for the docs, let me know.

Honza

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

* Re: SUBREGs and modes
  2000-08-02  9:30       ` Jan Hubicka
@ 2000-08-02 12:40         ` Geoff Keating
  0 siblings, 0 replies; 7+ messages in thread
From: Geoff Keating @ 2000-08-02 12:40 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc

Jan Hubicka <jh@suse.cz> writes:

> Don't know - perhaps it would be better to wait for the SUBREG_BYTE
> patches.  The prbolem I am having is that we prohibit SUBREGs of
> const_int s lurking around the RTL stream and currently gcse is
> creating them, since it fails to simplify the SUBREGs of constants
> substitued to registers with NON-SImode and WORDNUM nonzero. This
> also disables any const propagation on these beast too - in the CSE,
> gcse and combine :(

Actually, we don't.  It used to be that when cross-compiling you could
get constructs like:

(subreg:SF (const_int 0x40800000) 0)

but a patch I committed about two weeks ago causes this case to only
happen when the FP emulator is not in use, which at present only
happens on VMS.

Now, I wouldn't _recommend_ such things.  As you've noticed, it hurts
optimisation.  gen_lowpart_common is the routine that knows how to fix
them.

Also, the reason for the patch is that PREFERRED_RELOAD_CLASS doesn't
work properly in the presence of such subregs, and it was easier to
ban them than to fix it.
-- 
- Geoffrey Keating <geoffk@cygnus.com>

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

end of thread, other threads:[~2000-08-02 12:40 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-02  5:49 SUBREGs and modes Jan Hubicka
2000-08-02  5:58 ` Jakub Jelinek
2000-08-02  8:39 ` Joern Rennecke
2000-08-02  8:49   ` Jan Hubicka
2000-08-02  9:13     ` Joern Rennecke
2000-08-02  9:30       ` Jan Hubicka
2000-08-02 12:40         ` Geoff Keating

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).