On 7/13/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
Yes, but IIRC that was only for addressable things, not for registers.
Changing DECL_COMPLEX_GIMPLE_REG_P to DECL_GIMPLE_REG_P
and adding support for it for vector types has fixed this problem. In
fact now I can get vec_extract and vec_set (
Paolo Bonzini wrote on 07/13/06 11:55:
> But if you say this is dangerous, yes, I agree that the best thing to do
> is to treat VECTOR_TYPEs like COMPLEX_TYPEs and use
> DECL_COMPLEX_GIMPLE_REG_P. Does COMPOSITE_TYPE_P, and
> DECL_COMPOSITE_GIMPLE_REG_P sound good as names?
>
Yes, I think that s
them, IIUC. Reading should be ok.
This patch is sufficient for BIT_FIELD_REF on the LHS to be marked
correctly as addressable:
Index: ../../gcc/tree-ssa-operands.c
===
--- ../../gcc/tree-ssa-operands.c (revision 115364)
+++ ../.
On Jul 13, 2006, at 10:06 PM, Diego Novillo wrote:
That definitely seems wrong. We shouldn't be considering vector types
to be GIMPLE register types if we are going to be chunking them out
with
BIT_FIELD_REF. The verifier ought to check that.
I am thinking about cleaning this up by using
Andrew Pinski wrote on 07/13/06 08:37:
> #define vector __attribute__((vector_size(16) ))
>
> vector float f(vector float t, vector t1)
> {
> return t/t1;
> }
>
> -- Pinski
>
That definitely seems wrong. We shouldn't be considering vector types
to be GIMPLE register types if we are going to b
On Jul 13, 2006, at 9:32 PM, Diego Novillo wrote:
Got a test case where we produce BIT_FIELD_REF in
either
side of the assignment?
Well a simple one like for the RHS on PPC-linux-gnu with -maltivec
(and -O1):
#define vector __attribute__((vector_size(16) ))
vector float f(vector float
Andrew Pinski wrote on 07/13/06 03:27:
> I don't see anything in either tree.def or tree-ssa.texi which would
> cause the orginal non-gimplified tree to be invalid. So my question
> is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME
> invalid gimple?
>
SSA
PS http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02150.html added the
ability for having BIT_FIELD_REF on the LHS.
Yes, but IIRC that was only for addressable things, not for registers.
As Steven said, handling it would be a mess like it was for RTL SSA.
So, you Do Not Want this for
On 7/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 7/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> So I started to try to fold *(type*)(&vector_type_var) into
> BIT_FIELD_REF but I ran into a bug where the SSA messes
> itself up.
> This works for the right hand side just fine as
> BI
chard.
I don't see anything in either tree.def or tree-ssa.texi which would
cause the orginal non-gimplified tree to be invalid. So my question
is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME
invalid gimple?
I just looked into the mainline and saw that we actually produce
duce:
BIT_FIELD_REF = t_1 still even though t1_2 is killed
during the BIT_FIELD_REF.
I don't see anything in either tree.def or tree-ssa.texi which would
cause the orginal non-gimplified tree to be invalid. So my question
is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME
invalid g
11 matches
Mail list logo
