Re: "exotic" machine modes

Re: "exotic" machine modes

[Jan Beulich]

>Some general comments.
>- Sending mail to gcc-bugs is really not very useful.  gcc-bugs is 
>primarily used for bugzilla traffic.  Anything that isn't bugzilla 
>traffic is likely to be missed.  You are better off sending questions

>like this to the gcc list.

Hmm, then http://gcc.gnu.org/lists.html is wrong in saying "gcc-bugs 
is a relatively high volume list for bug reports and general discussion
about bugs in GCC."

>...

Jan

Re: "exotic" machine modes

[Andrew Walrond]

On Monday 24 May 2004 13:40, Jan Beulich wrote:
> >Some general comments.
> >- Sending mail to gcc-bugs is really not very useful.  gcc-bugs is
> >primarily used for bugzilla traffic.  Anything that isn't bugzilla
> >traffic is likely to be missed.  You are better off sending questions
> >
> >like this to the gcc list.
>
> Hmm, then http://gcc.gnu.org/lists.html is wrong in saying "gcc-bugs
> is a relatively high volume list for bug reports and general discussion
> about bugs in GCC."
>

Agreed; I just made the same mistake. And I've been subscribed to gcc for 
years.

Re: "exotic" machine modes

[Jim Wilson]

Jan Beulich wrote:
> While putting together a generic vector mode test set for the test suite
> I ran into an internal compiler error when dealing with V16SF and V4DF

Some general comments.
- Sending mail to gcc-bugs is really not very useful.  gcc-bugs is 
primarily used for bugzilla traffic.  Anything that isn't bugzilla 
traffic is likely to be missed.  You are better off sending questions 
like this to the gcc list.
- You didn't mention the gcc version.  It appears you are looking at old 
gcc sources.  If you want to do development, or comment on development, 
you have to look at current development sources.  Since I am not sure 
what gcc sources you are looking at, I am not sure how to answer some of 
the questions.
- I believe that there are others working on vector testsuites, there 
may already be one in current sources.
- Most gcc extensions are implemented first, and then designed later, so 
you can't expect them to behave reasonably in corner cases until after a 
few years of bug fixing.
- There are a number of other people working on the vector extensions. 
Probably none of them saw this message.

> - Since there is no user of V4DF and the compiler doesn't implement it
> properly, shouldn't the type node generation for it be eliminated?

It is already gone.  However, it may have been replaced with other code 
that might cause trouble for you depending on what exactly the bug is 
that you are reporting.  Testcases are usually better than trying to 
describe problems.

> - Since there is on a single acrchitecture using V16SF (sh), shouldn't
> it be moved there?

The type node is gone.  It is still in machmode.def, but that seems to 
be relatively harmless.  Again, there are other changes here.

> - Shouldn't, if the compiler doesn't support them anyway, any modes for
> which no type nodes are generated be removed from machmode.def? Or
> alternatively, should the type node generation directly depend on the
> set of available modes?

The modes are needed for RTL operations.  It is possible (since about 
last November) for targets to define their own modes, so we could 
perhaps move things from machmode.def to targets if necessary.  It isn't 
clear that there is a problem here though.

> - Alternatively, if the compiler intends to generically support these
> vector modes, shouldn't the above mentioned abort() cases in expmed.c be
> dealt with?

If you can make the compiler abort, then yes, something is broken.  The 
fix depends on what exactly the problem is.  For that, a testcase would 
be helpful.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

"exotic" machine modes

[Jan Beulich]

While putting together a generic vector mode test set for the test suite
I ran into an internal compiler error when dealing with V16SF and V4DF
under -O2 and -O3. While I could obviously make those expected failures,
this doesn't seem correct. Instead, I'd rather put under question the
existence of any of the modes for which int_mode_for_mode() returns
BLKmode (which will always trigger the abort()s in
extract_bit_field()/store_bit_field()), namely because of the total
width exceeding that of TImode. The list of these would be V4DI, V8SI,
V8DI, V4DF, V8SF, V8DF, and V16SF (possibly also XC, TC, and CTI). Now,
for all of these except V4DF and V16SF type nodes are not being created
(at least not in the architecture independent part of the tree, making
the types mostly unusable), preventing the internal error by way of
earlier meaningful error messages.
The questions thus are:
- Since there is no user of V4DF and the compiler doesn't implement it
properly, shouldn't the type node generation for it be eliminated?
- Since there is on a single acrchitecture using V16SF (sh), shouldn't
it be moved there?
- Shouldn't, if the compiler doesn't support them anyway, any modes for
which no type nodes are generated be removed from machmode.def? Or
alternatively, should the type node generation directly depend on the
set of available modes?
- Alternatively, if the compiler intends to generically support these
vector modes, shouldn't the above mentioned abort() cases in expmed.c be
dealt with?

Thanks, Jan