* naked zero_extracts longer than a word.
@ 2009-05-11 16:30 Kenneth Zadeck
2009-05-11 17:14 ` Ian Lance Taylor
2009-05-11 17:26 ` Jim Wilson
0 siblings, 2 replies; 8+ messages in thread
From: Kenneth Zadeck @ 2009-05-11 16:30 UTC (permalink / raw)
To: gcc, rdsandiford, law, Bonzini, Paolo, wilson
Would those that know, (or even those that are just generally vocal) be
willing to support a change rtl.texi for sign_extract (and by
implication, zero_extract) from
If @var{loc} is in memory, its mode must be a single-byte integer mode.
If @var{loc} is in a register, the mode to use is specified by the
operand of the @code{insv} or @code{extv} pattern
(@pxref{Standard Names}) and is usually a full-word integer mode,
which is the default if none is specified.
to a version that explicitly prohibits the use of a mode longer than a word?
The back ends do not appear to support this anyway.
Kenny
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: naked zero_extracts longer than a word.
2009-05-11 16:30 naked zero_extracts longer than a word Kenneth Zadeck
@ 2009-05-11 17:14 ` Ian Lance Taylor
2009-05-11 19:17 ` Paolo Bonzini
2009-05-11 19:26 ` Toon Moene
2009-05-11 17:26 ` Jim Wilson
1 sibling, 2 replies; 8+ messages in thread
From: Ian Lance Taylor @ 2009-05-11 17:14 UTC (permalink / raw)
To: Kenneth Zadeck; +Cc: gcc, rdsandiford, law, Bonzini, Paolo, wilson
Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> Would those that know, (or even those that are just generally vocal) be
> willing to support a change rtl.texi for sign_extract (and by
> implication, zero_extract) from
>
> If @var{loc} is in memory, its mode must be a single-byte integer mode.
> If @var{loc} is in a register, the mode to use is specified by the
> operand of the @code{insv} or @code{extv} pattern
> (@pxref{Standard Names}) and is usually a full-word integer mode,
> which is the default if none is specified.
>
> to a version that explicitly prohibits the use of a mode longer than a word?
>
> The back ends do not appear to support this anyway.
I guess the obvious counterexample would be a processor which supported
vector registers and supported bitfield operations on such registers. I
don't know of any such processors. The restriction would probably be
fine in practice, but why do you want to make it?
Ian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: naked zero_extracts longer than a word.
2009-05-11 16:30 naked zero_extracts longer than a word Kenneth Zadeck
2009-05-11 17:14 ` Ian Lance Taylor
@ 2009-05-11 17:26 ` Jim Wilson
2009-05-11 19:18 ` Paolo Bonzini
1 sibling, 1 reply; 8+ messages in thread
From: Jim Wilson @ 2009-05-11 17:26 UTC (permalink / raw)
To: Kenneth Zadeck; +Cc: gcc, rdsandiford, law, Bonzini, Paolo
On Mon, 2009-05-11 at 10:52 -0400, Kenneth Zadeck wrote:
> Would those that know, (or even those that are just generally vocal) be
> willing to support a change rtl.texi for sign_extract (and by
> implication, zero_extract) from ...
> to a version that explicitly prohibits the use of a mode longer than a word?
Just grepping, I can find one example that currently uses this. See the
x86_movdicc_0_m1_se pattern in the i386.md file. However, I suspect
this is a bug, and that the pattern should be using TARGET_64. I don't
have x86 manuals handy.
Jim
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: naked zero_extracts longer than a word.
2009-05-11 17:14 ` Ian Lance Taylor
@ 2009-05-11 19:17 ` Paolo Bonzini
2009-05-11 20:07 ` Ian Lance Taylor
2009-05-11 19:26 ` Toon Moene
1 sibling, 1 reply; 8+ messages in thread
From: Paolo Bonzini @ 2009-05-11 19:17 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Kenneth Zadeck, gcc, rdsandiford, law, wilson
Ian Lance Taylor wrote:
> Kenneth Zadeck <zadeck@naturalbridge.com> writes:
>
>> Would those that know, (or even those that are just generally vocal) be
>> willing to support a change rtl.texi for sign_extract (and by
>> implication, zero_extract) from
>>
>> If @var{loc} is in memory, its mode must be a single-byte integer mode.
>> If @var{loc} is in a register, the mode to use is specified by the
>> operand of the @code{insv} or @code{extv} pattern
>> (@pxref{Standard Names}) and is usually a full-word integer mode,
>> which is the default if none is specified.
>>
>> to a version that explicitly prohibits the use of a mode longer than a word?
>>
>> The back ends do not appear to support this anyway.
>
> I guess the obvious counterexample would be a processor which supported
> vector registers and supported bitfield operations on such registers. I
> don't know of any such processors. The restriction would probably be
> fine in practice, but why do you want to make it?
No, actually the question I asked Kenny was not about modes wider than a
word, but about hard registers spanning more than one hard registers.
That would be something like
(set (reg:SI 0) (zero_extract:SI (reg:DI 2)
(const_int 32) (const_int 16)))
with word_mode == SImode. Currently DF would mishandle this; Kenny
thought the doc should be changed if this is actually unsupported.
Paolo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: naked zero_extracts longer than a word.
2009-05-11 17:26 ` Jim Wilson
@ 2009-05-11 19:18 ` Paolo Bonzini
0 siblings, 0 replies; 8+ messages in thread
From: Paolo Bonzini @ 2009-05-11 19:18 UTC (permalink / raw)
To: Jim Wilson; +Cc: Kenneth Zadeck, gcc, rdsandiford, law
Jim Wilson wrote:
> On Mon, 2009-05-11 at 10:52 -0400, Kenneth Zadeck wrote:
>> Would those that know, (or even those that are just generally vocal) be
>> willing to support a change rtl.texi for sign_extract (and by
>> implication, zero_extract) from ...
>> to a version that explicitly prohibits the use of a mode longer than a word?
>
> Just grepping, I can find one example that currently uses this. See the
> x86_movdicc_0_m1_se pattern in the i386.md file. However, I suspect
> this is a bug, and that the pattern should be using TARGET_64. I don't
> have x86 manuals handy.
Indeed sbbq does not exist on 32-bit targets.
Paolo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: naked zero_extracts longer than a word.
2009-05-11 17:14 ` Ian Lance Taylor
2009-05-11 19:17 ` Paolo Bonzini
@ 2009-05-11 19:26 ` Toon Moene
1 sibling, 0 replies; 8+ messages in thread
From: Toon Moene @ 2009-05-11 19:26 UTC (permalink / raw)
To: Ian Lance Taylor
Cc: Kenneth Zadeck, gcc, rdsandiford, law, Bonzini, Paolo, wilson
Ian Lance Taylor wrote:
> I guess the obvious counterexample would be a processor which supported
> vector registers and supported bitfield operations on such registers. I
> don't know of any such processors.
The Control Data Cyber 205 (roughly '75-'85).
You could write the inner loop of the Sieve of Eratosthenes as a single
vector instruction.
We do not have a (supported) port for that architecture.
Kind regards,
--
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: naked zero_extracts longer than a word.
2009-05-11 19:17 ` Paolo Bonzini
@ 2009-05-11 20:07 ` Ian Lance Taylor
2009-05-11 20:11 ` Daniel Jacobowitz
0 siblings, 1 reply; 8+ messages in thread
From: Ian Lance Taylor @ 2009-05-11 20:07 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Kenneth Zadeck, gcc, rdsandiford, law, wilson
Paolo Bonzini <bonzini@gnu.org> writes:
> Ian Lance Taylor wrote:
>> Kenneth Zadeck <zadeck@naturalbridge.com> writes:
>>
>>> Would those that know, (or even those that are just generally vocal) be
>>> willing to support a change rtl.texi for sign_extract (and by
>>> implication, zero_extract) from
>>>
>>> If @var{loc} is in memory, its mode must be a single-byte integer mode.
>>> If @var{loc} is in a register, the mode to use is specified by the
>>> operand of the @code{insv} or @code{extv} pattern
>>> (@pxref{Standard Names}) and is usually a full-word integer mode,
>>> which is the default if none is specified.
>>>
>>> to a version that explicitly prohibits the use of a mode longer than a word?
>>>
>>> The back ends do not appear to support this anyway.
>>
>> I guess the obvious counterexample would be a processor which supported
>> vector registers and supported bitfield operations on such registers. I
>> don't know of any such processors. The restriction would probably be
>> fine in practice, but why do you want to make it?
>
> No, actually the question I asked Kenny was not about modes wider than a
> word, but about hard registers spanning more than one hard registers.
>
> That would be something like
>
> (set (reg:SI 0) (zero_extract:SI (reg:DI 2)
> (const_int 32) (const_int 16)))
>
> with word_mode == SImode. Currently DF would mishandle this; Kenny
> thought the doc should be changed if this is actually unsupported.
I feel reasonably confident that there will never be a processor which
supports a bitfield instruction which operates on multiple hard register
simultaneously. I don't think that is a case we need to worry about.
(I will now wait for somebody to post an example of such a processor.)
Ian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: naked zero_extracts longer than a word.
2009-05-11 20:07 ` Ian Lance Taylor
@ 2009-05-11 20:11 ` Daniel Jacobowitz
0 siblings, 0 replies; 8+ messages in thread
From: Daniel Jacobowitz @ 2009-05-11 20:11 UTC (permalink / raw)
To: Ian Lance Taylor
Cc: Paolo Bonzini, Kenneth Zadeck, gcc, rdsandiford, law, wilson
On Mon, May 11, 2009 at 12:25:50PM -0700, Ian Lance Taylor wrote:
> I feel reasonably confident that there will never be a processor which
> supports a bitfield instruction which operates on multiple hard register
> simultaneously. I don't think that is a case we need to worry about.
>
> (I will now wait for somebody to post an example of such a processor.)
I can't quite do that, but here's a likely scenario: registers which
GCC views as separate but are really combined. For instance, if ARM
NEON supported bitfield insert/extract (which it unsurprisingly does
not), we'd have a problem: the 'qN' registers are two 'dN' registers
concatenated, and GCC only knows about them once.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-05-11 19:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-11 16:30 naked zero_extracts longer than a word Kenneth Zadeck
2009-05-11 17:14 ` Ian Lance Taylor
2009-05-11 19:17 ` Paolo Bonzini
2009-05-11 20:07 ` Ian Lance Taylor
2009-05-11 20:11 ` Daniel Jacobowitz
2009-05-11 19:26 ` Toon Moene
2009-05-11 17:26 ` Jim Wilson
2009-05-11 19:18 ` Paolo Bonzini
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).