On Wed, 19 Apr 2006, Daniel Berlin wrote:
make_node does memset, but the loop above is after the call to make_node.
I guess we didn't hit the problem just because tsubst_copy_and_build()
(where build_x_binary_op (ARRAY_REF is) is never called for array_ref when
processing_template_decl is non
On Apr 19, 2006, at 1:37 PM, sean yang wrote:
Thanks a lot. Here I further have a question, which is about the
GIMPLE grammar. Thanks for the help again:
I looked at walk_stmt(), which is basically how I want to walk
through the function body (&DECL_SAVED_TREE(fn) ).
This seems like a
make_node does memset, but the loop above is after the call to
make_node.
I guess we didn't hit the problem just because tsubst_copy_and_build()
(where build_x_binary_op (ARRAY_REF is) is never called for
array_ref when processing_template_decl is non zero.
Probably.
Unfortunately, TREE_O
> The generator programs (e.g. build/genattrtab) output #line
> directives before code which has been copied from the machine
> description files, so the debugger will show you the correct
> file. But this then causes trouble when single stepping through code
> which wasn't included from the .md fi
On Wed, 19 Apr 2006, Daniel Berlin wrote:
On Apr 19, 2006, at 4:48 PM, Alexey Starovoytov wrote:
Hi,
Is this a bug that we were lucky not to hit?
cp/pt.c:
return build_x_binary_op (ARRAY_REF, op1, RECUR (TREE_OPERAND (t, 1)),
/*overloaded_p=*/NULL);
tree
build_x_
On Apr 19, 2006, at 4:48 PM, Alexey Starovoytov wrote:
Hi,
Is this a bug that we were lucky not to hit?
cp/pt.c:
return build_x_binary_op (ARRAY_REF, op1, RECUR (TREE_OPERAND (t,
1)),
/*overloaded_p=*/NULL);
tree
build_x_binary_op (enum tree_code code, tree ar
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > I agree with everything you have said. I suppose I'm a bit unclear
| > about this:
| >
| >already defined. __value_cast would just be an alias for
| >static_cast for non-vector types, but for vector types it woul
Hi,
Is this a bug that we were lucky not to hit?
cp/pt.c:
return build_x_binary_op (ARRAY_REF, op1, RECUR (TREE_OPERAND (t, 1)),
/*overloaded_p=*/NULL);
tree
build_x_binary_op (enum tree_code code, tree arg1, tree arg2,
bool *overloaded_p)
{
...
On Wed, Apr 19, 2006 at 06:01:54PM -0400, Andrew Pinski wrote:
> > BTW, If anyone is interested in working on SEE for x86-64, please drop
> > me a line.
>
> Why not do the comunication in public?
Sure. Let me give a try.
If I understand it correctly, the current SEE implementation tries to
elim
Gabriel Dos Reis wrote:
> I agree with everything you have said. I suppose I'm a bit unclear
> about this:
>
>already defined. __value_cast would just be an alias for
>static_cast for non-vector types, but for vector types it would do a
>value-preserving conversion, even if C-style
> BTW, If anyone is interested in working on SEE for x86-64, please drop
> me a line.
Why not do the comunication in public?
-- Pinski
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Chris Lattner wrote:
| >
| > On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote:
| >
| >> Let's accept that both the bit-preserving and value-preserving
| >> conversions would be useful. How do we differentiate the two?
| >>
| >
| >> For vectors, these
On Wed, Apr 19, 2006 at 02:47:54PM -0700, Mark Mitchell wrote:
> On the regression front, we have 61 open serious (P3 or higher)
> regressions that are specific to 4.2. I have not triaged these, so
> there is a good chance than more than a few relate to Ada, Java,
> Fortran, or non-primary, non-se
On the regression front, we have 61 open serious (P3 or higher)
regressions that are specific to 4.2. I have not triaged these, so
there is a good chance than more than a few relate to Ada, Java,
Fortran, or non-primary, non-secondary platforms. I think that,
therefore, the regressions which are
Chris Lattner wrote:
>
> On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote:
>
>> Let's accept that both the bit-preserving and value-preserving
>> conversions would be useful. How do we differentiate the two?
>>
>
>> For vectors, these operators would apply to each element, and then
>> return a
On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote:
Let's accept that both the bit-preserving and value-preserving
conversions would be useful. How do we differentiate the two?
For vectors, these operators would apply to each element, and then
return a vector with the same number of elements
On Apr 19, 2006, at 2:17 PM, David Edelsohn wrote:
Mike Stump writes:
Mike> Is there a remaining purpose for pmode?
Mike> From rs6000.c:
Mike> void
Mike> rs6000_initialize_trampoline (rtx addr, rtx fnaddr, rtx cxt)
Mike> {
Mike> enum machine_mode pmode = Pmode;
The variable "pmode"
> Mike Stump writes:
Mike> Is there a remaining purpose for pmode?
Mike> From rs6000.c:
Mike> void
Mike> rs6000_initialize_trampoline (rtx addr, rtx fnaddr, rtx cxt)
Mike> {
Mike> enum machine_mode pmode = Pmode;
The variable "pmode" is used throughout that function. Are you
questio
Joe Buck wrote:
> On Wed, Apr 19, 2006 at 01:56:46PM -0700, Mark Mitchell wrote:
>> Let's accept that both the bit-preserving and value-preserving
>> conversions would be useful. How do we differentiate the two?
>>
>> In C++, we could invent __value_cast and __bitwise_cast. For
>> example, __bitw
On Wed, Apr 19, 2006 at 01:56:46PM -0700, Mark Mitchell wrote:
> Let's accept that both the bit-preserving and value-preserving
> conversions would be useful. How do we differentiate the two?
>
> In C++, we could invent __value_cast and __bitwise_cast. For
> example, __bitwise_cast(3.0f) would b
Janis Johnson wrote:
> Oops. I guess we can blame the AltiVec PIM after all.
I think we certainly want to honor the existing standards here,
including the AltiVec PIM and SPE specification. Perhaps we should
leave the issue of the default behavior aside for the moment. I think
it's clear what
Thanks a lot. Here I further have a question, which is about the GIMPLE
grammar. Thanks for the help again:
I looked at walk_stmt(), which is basically how I want to walk through the
function body (&DECL_SAVED_TREE(fn) ).
-
Paolo Bonzini wrote:
We use to call this "benchmarketing"
I don't see why GNU would want to do that for anything.
Because (that's unfortunate, agreed) GCC does need some marketing.
Unfortunately people compare GCC with icc (or other compilers) using
SPEC,
Hmmm, that's not my experience
Is there a remaining purpose for pmode?
From rs6000.c:
void
rs6000_initialize_trampoline (rtx addr, rtx fnaddr, rtx cxt)
{
enum machine_mode pmode = Pmode;
On Apr 19, 2006, at 11:52 AM, Daniel Berlin wrote:
So is this an object lesson for why optimizing for benchmarks is
a bad
idea?
If you're inclined to believe this, you could find a confirming
instance here, but there are other lessons that could be drawn. If
you go back to the original threa
There is the Spe PEM as well (Freescale 8540/8548). On the Spe we
defined a vector type that has no
definition of vector elements. (__ev64_opaque__).
It was designed such that casting from this type to any other vector
type of the same
size can only be accomplished by bit-preserving conversion
> > So is this an object lesson for why optimizing for benchmarks is a bad
> > idea?
>
> If you're inclined to believe this, you could find a confirming
> instance here, but there are other lessons that could be drawn. If
> you go back to the original thread, you'll see this from Toon Moene:
Eric Botcazou wrote:
Unfortunately, GCC needs to do marketing of performance, just like
other compilers.
Not so obvious premise I'd personally think. Where would it come from?
Right, and even in the marketing domain, performance is just one
feature, and by no means the most important (compar
On Apr 19, 2006, at 12:04 AM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in
<[EMAIL PROTECTED]>:
This is in fact, not terribly surprising, since the algorithm used
was the
result of Sebastian and I sitting at my whiteboard for 30 minutes
trying to
figure ou
>
> I think, like Ian, that conversions from V4SF to V4SI, via an ordinary
> cast, should perform a conversion; this should be the same as converting
> each of the individual floats to int. Then, since the bit-preserving
> conversion is also useful, we should have another syntax for that.
>
> Ho
On Wed, Apr 19, 2006 at 05:53:30PM +0100, Andrew Haley wrote:
> Janis Johnson writes:
> > On Wed, Apr 19, 2006 at 05:30:54PM +0200, Paolo Bonzini wrote:
> > >
> > > The C spec for Altivec (not the ISA) is a horrible spec that set a
> > > horrible de facto standard. To some extent, gcc alread
Janis Johnson writes:
> On Wed, Apr 19, 2006 at 05:30:54PM +0200, Paolo Bonzini wrote:
> >
> > The C spec for Altivec (not the ISA) is a horrible spec that set a
> > horrible de facto standard. To some extent, gcc already departed from
> > Altivec, for example by disallowing the (vector in
On Wed, Apr 19, 2006 at 05:30:54PM +0200, Paolo Bonzini wrote:
>
> The C spec for Altivec (not the ISA) is a horrible spec that set a
> horrible de facto standard. To some extent, gcc already departed from
> Altivec, for example by disallowing the (vector int) (1, 2, 3, 4) syntax
> -- notice t
I think, like Ian, that conversions from V4SF to V4SI, via an ordinary
cast, should perform a conversion; this should be the same as converting
each of the individual floats to int. Then, since the bit-preserving
conversion is also useful, we should have another syntax for that.
However, the Alti
[EMAIL PROTECTED] wrote:
Just to follow up on this email since I looked into some of the
issues a little more last night.
The problem here is the translation table is broken.
Here is what we get on powerpc-darwin:
Class cover:
FLOAT_REGS NON_FLOAT_REGS
Class translation:
NO_REGS -> NO_REGS
Hey folks. I'm going to add "visibility" as a bugzilla keyword, and
they go through and tag the appropriate entries in bugzilla with it.
Searches for these types of problems are getting pretty ungainly, and
some kind of organizing principle should/can be applied.
-benjamin
> Of course, it is not practically doable, to have vector typecasts
> preserve values (FLOAT_EXPR) on SSE and bits (VIEW_CONVERT_EXPR) on
> Altivec. The availability of generic vector types, which were
> overhauled in order to provide portable vector support even for machines
> without SIMD ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aldy Hernandez wrote:
> How does this look?
>
I think I'd rather fix DCE/DSE independently of SFTs. Excessive
reliance on the pseudo scalarization given by SFTs brings problems of
its own.
We could explore that idea we talked about before where we
> "Vector types can be cast to other vector types. The cast does not
> perform a conversion: it preserves the 128-bit pattern, but not
> necessarily the value. A cast between a vector type and a scalar type is
> not allowed."
Everything becomes clear. I would never have started this thread
> Unfortunately, GCC needs to do marketing of performance, just like
> other compilers.
Not so obvious premise I'd personally think. Where would it come from?
--
Eric Botcazou
Paolo Bonzini writes:
>
> > > The short answer is that AltiVec dictated this behavior. :-( Longer
> > > answers were given by Ian and Paul, and I agree with them.
> >
> > OK, so: firstly, is this behaviour actually documented anywhere? In
> > AltiVec docs, maybe?
> >
> http://publi
On Apr 19, 2006, at 12:04 AM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in
<[EMAIL PROTECTED]>:
This is in fact, not terribly surprising, since the algorithm used
was the
result of Sebastian and I sitting at my whiteboard for 30 minutes
trying to
figure
> The short answer is that AltiVec dictated this behavior. :-( Longer
> answers were given by Ian and Paul, and I agree with them.
OK, so: firstly, is this behaviour actually documented anywhere? In
AltiVec docs, maybe?
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?
Paolo Bonzini writes:
> Andrew Haley wrote:
> > Converting a vector of floats (via a cast) to a vector of ints of the
> > same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> > converted. This is different from a cast from scalar float to int,
> > where a conversion is per
Andrew Haley wrote:
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from scalar float to int,
where a conversion is performed.
From what I can see of the source,
We use to call this "benchmarketing"
I don't see why GNU would want to do that for anything.
Because (that's unfortunate, agreed) GCC does need some marketing.
Unfortunately people compare GCC with icc (or other compilers) using
SPEC, and you want them to compare apples to apples -- compile
On Apr 19, 2006, at 9:00 AM, Neil Booth wrote:
So is this an object lesson for why optimizing for benchmarks is a
bad
idea?
We use to call this "benchmarketing"
I don't see why GNU would want to do that for anything.
Paul Brook <[EMAIL PROTECTED]> writes:
> > In general there is a conflict within gcc between treating vectors as
> > unitary types and treating them as collections. In this case we are
> > treating them as unary. However, I think that by analogy to the way
> > we handle arithmetic, and given the
Kai Henningsen wrote:-
> [EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in <[EMAIL PROTECTED]>:
>
> > This is in fact, not terribly surprising, since the algorithm used was the
> > result of Sebastian and I sitting at my whiteboard for 30 minutes trying to
> > figure out what we'd need to d
Paul Brook <[EMAIL PROTECTED]> writes:
[...]
| It seems like straight bit-copy "conversion" is a useful feature, so I guess
| we'd want to invent some syntax for this.
memcpy?
-- Gaby
Ian Lance Taylor writes:
[...]
| That is, I think this is a bug.
I agree.
-- Gaby
On Wednesday 19 April 2006 14:41, Ian Lance Taylor wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
> > Converting a vector of floats (via a cast) to a vector of ints of the
> > same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> > converted. This is different from a cast fro
Andrew Haley <[EMAIL PROTECTED]> writes:
> Converting a vector of floats (via a cast) to a vector of ints of the
> same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> converted. This is different from a cast from scalar float to int,
> where a conversion is performed.
In gen
Daniel Jacobowitz wrote:
On Wed, Apr 19, 2006 at 08:58:59AM -0400, Robert Dewar wrote:
Andrew Haley wrote:
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from
On Wed, Apr 19, 2006 at 08:58:59AM -0400, Robert Dewar wrote:
> Andrew Haley wrote:
> >Converting a vector of floats (via a cast) to a vector of ints of the
> >same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> >converted. This is different from a cast from scalar float to in
Andrew Haley wrote:
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from scalar float to int,
where a conversion is performed.a
Yes, that's the way C is defined
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from scalar float to int,
where a conversion is performed.
>From what I can see of the source, this is deliberate.
[EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in <[EMAIL PROTECTED]>:
> This is in fact, not terribly surprising, since the algorithm used was the
> result of Sebastian and I sitting at my whiteboard for 30 minutes trying to
> figure out what we'd need to do to make swim happy :).
> This w
> But with gcc version greater than 3.0, It allocates 104 bytes for the
> stack of a new function.
112 actually on Solaris 7 and later.
> Can anyone please let me know the reason of the difference of 8 bytes?
Obscure internal hack. :-)
/* Offset within stack frame to start allocating local vari
Hi All
While compiling code for SPARC Architecture, Its seems reasonable that
when calling a new function, stack Size of 92 + 4(for alignment) is
allocated. But
with gcc version greater than 3.0, It allocates 104 bytes for the
stack of a new function.
Can anyone please let me know the reason of t
60 matches
Mail list logo
