Unaligned double

Unaligned double

[Mark Klein]

Hi.

The following used to work on 2.95.x and fails on 3.0.x for PA 1.0
semantics:

class ua_double
{
     double l;
public:
    ua_double &operator =(double l_) { l = l_; return *this; };
    operator double () { return l; };
}__attribute__((aligned(2), packed));

void addHoldFile(void);

void addHoldFile ()
{
    double dpAmount;
    struct
    {
       long lVal;
       ua_double dpAmount;
    } saRec;

    dpAmount = saRec.dpAmount;
}

...

(insn 28 26 30 (set (subreg:SI (reg:DF 96) 1)
         (reg:SI 102)) 68 {*pa.md:2088} (nil)
     (expr_list:REG_DEAD (reg:SI 102)
         (nil)))

which becomes:

(insn 68 28 65 (set (reg:SI 43 %fr9R [42])
         (reg:SI 21 %r21)) 68 {*pa.md:2088} (nil)
     (nil))

[snip]

test.cc: In member function `ua_double::operator double()':
test.cc:6: Insn does not satisfy its constraints:

(insn 68 28 30 (set (reg:SI 43 %fr9R [42])
         (reg:SI 21 %r21)) 68 {*pa.md:2088} (nil)
     (nil))
test.cc:6: Internal compiler error in extract_constrain_insn_cached, at recog.c
    :2133
Please submit a full bug report,

Note that I am using PA 1.0 as the architecture and %fr9R should not be
used. In fact:

regno: 43, not_usable: 1, used_by_other_reload: 0, mode: DF, mode_ok: 0

I can not figure out how or where %fr9R is getting emitted.

Any clues would be appreciated.

Regards,


M.
--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--

Re: Unaligned double

[Joern Rennecke]

> (insn 28 26 30 (set (subreg:SI (reg:DF 96) 1)
>          (reg:SI 102)) 68 {*pa.md:2088} (nil)
>      (expr_list:REG_DEAD (reg:SI 102)
>          (nil)))
> 
> which becomes:
> 
> (insn 68 28 65 (set (reg:SI 43 %fr9R [42])
>          (reg:SI 21 %r21)) 68 {*pa.md:2088} (nil)
>      (nil))

The way the insn number changes hints that this is probably done by combine.
You can verify this by displaying the insns in question before and after
the call to combine_instructions.  If this is the case, you can get a
closer look at what happens by setting a breakpoint at try_combine with
a condition i3->fld[0].rtint == 68.  If you are lucky, it is a straight
3-insn combination and you can use the condition
i3->fld[0].rtint == 68 && i1 && i1->fld[0].rtint == 28

Note that the subreg handling has been completely overhauled with the
SUBREG_BYTE patch.  We used to need CLASS_CANNOT_CHANGE_SIZE /
CLASS_CANNOT_CHANGE_MODE_P in some instances where we don't need them
any longer.

pa32-regs.h is rather odd in that it defines CLASS_CANNOT_CHANGE_MODE
as NO_REGS and then goes on to define CLASS_CANNOT_CHANGE_MODE_P to
reject size-changing mode changes.  The latter is made ineffective by the
former.

> (insn 68 28 30 (set (reg:SI 43 %fr9R [42])
>          (reg:SI 21 %r21)) 68 {*pa.md:2088} (nil)
>      (nil))
> test.cc:6: Internal compiler error in extract_constrain_insn_cached, at recog.c
>     :2133
> Please submit a full bug report,
> 
> Note that I am using PA 1.0 as the architecture and %fr9R should not be
> used. In fact:

If a 32 bit floating point move is OK but the calculated register number
is wrong, you should look into defining SUBREG_REGNO_OFFSET.  Note that
the last time I looked, the framework for SUBREG_REGNO_OFFSET did not
work in some trivial manner, and needed fixing.

If a 32 bit floating point move is generally wrong, try defining
CLASS_CANNOT_CHANGE_MODE to FP_REGS.

Re: Unaligned double

[Joern Rennecke]

> The way the insn number changes hints that this is probably done by combine.

P.S.: Another possibility is that insn 68 was emitted by reload.

Re: Unaligned double

[law]

  In message < 4.2.0.58.20011015091248.00ad8690@dis.dis.com >you write:
  > Hi.
  > 
  > The following used to work on 2.95.x and fails on 3.0.x for PA 1.0
  > semantics:
  > 
  > class ua_double
  > {
  >      double l;
  > public:
  >     ua_double &operator =(double l_) { l = l_; return *this; };
  >     operator double () { return l; };
  > }__attribute__((aligned(2), packed));
  > 
  > void addHoldFile(void);
  > 
  > void addHoldFile ()
  > {
  >     double dpAmount;
  >     struct
  >     {
  >        long lVal;
  >        ua_double dpAmount;
  >     } saRec;
  > 
  >     dpAmount = saRec.dpAmount;
  > }
  > 
  > ...
  > 
  > (insn 28 26 30 (set (subreg:SI (reg:DF 96) 1)
  >          (reg:SI 102)) 68 {*pa.md:2088} (nil)
  >      (expr_list:REG_DEAD (reg:SI 102)
  >          (nil)))
  > 
  > which becomes:
  > 
  > (insn 68 28 65 (set (reg:SI 43 %fr9R [42])
  >          (reg:SI 21 %r21)) 68 {*pa.md:2088} (nil)
  >      (nil))
  > 
  > [snip]
  > 
  > test.cc: In member function `ua_double::operator double()':
  > test.cc:6: Insn does not satisfy its constraints:
  > 
  > (insn 68 28 30 (set (reg:SI 43 %fr9R [42])
  >          (reg:SI 21 %r21)) 68 {*pa.md:2088} (nil)
  >      (nil))
  > test.cc:6: Internal compiler error in extract_constrain_insn_cached, at rec
  > og.c
  >     :2133
  > Please submit a full bug report,
  > 
  > Note that I am using PA 1.0 as the architecture and %fr9R should not be
  > used. In fact:
  > 
  > regno: 43, not_usable: 1, used_by_other_reload: 0, mode: DF, mode_ok: 0
  > 
  > I can not figure out how or where %fr9R is getting emitted.
  > 
  > Any clues would be appreciated.
I'd start by looking to see if local, global or reload assigned %fr9R to
pseudo 96.  That will determine how to proceed.
jeff

Re: Unaligned double

[Joern Rennecke]

> resolved. But, I'm not sure if that breaks anything else because
> I'm not sure why it was NO_REGS for pa32 and FP_REGS for pa64.

Changing CLASS_CANNOT_CHANGE_MODE from NO_REGS to a non-empty register class
should never cause the compiler to generate wrong code, unless something
else is broken.  However, if needlessly defined, it can cause worse
code generation (i.e. larger & slower code) due to the restricted choices
of the register allocator.  For targets with very tight register resources
(which the pa is not), it could also lead to reload aborts if it pushes
the maximum amount of registers of any class required for reload beyond
what is available.

So the main concern here would be the efficiency of the emitted code.

-- 
Joern Rennecke                  |            gcc expert for hire
amylaar@onetel.net.uk           |  send enquiries to: jwr_jobs@onetel.net.uk

Re: Unaligned double

[Mark Klein]

 >I'd start by looking to see if local, global or reload assigned %fr9R to
 >pseudo 96.  That will determine how to proceed.
 >jeff
 >

test.cc.19.lreg contains:

(insn 28 26 30 (set (subreg:SI (reg:DF 96) 1)
         (reg:SI 102)) 68 {*pa.md:2088} (nil)
     (expr_list:REG_DEAD (reg:SI 102)
         (nil)))

and test.cc.20.greg contains:


(insn 62 26 28 (set (reg:DF 42 %fr9)
         (reg:DF 40 %fr8 [96])) 111 {*pa.md:2917} (nil)
     (nil))

(insn 28 62 68 (set (reg:SI 21 %r21)
         (reg:SI 19 %r19 [102])) 68 {*pa.md:2088} (nil)
     (nil))

(insn 68 28 65 (set (reg:SI 43 %fr9R [42])
         (reg:SI 21 %r21)) 68 {*pa.md:2088} (nil)
     (nil))

So that should indicate global.

BTW - I took Joern Rennecke's suggestion about setting
CLASS_CANNOT_CHANGE_MODE to FP_REGS and the issue appears to be
resolved. But, I'm not sure if that breaks anything else because
I'm not sure why it was NO_REGS for pa32 and FP_REGS for pa64.

Regards,


M.


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: Unaligned double

[Richard Henderson]

On Tue, Oct 16, 2001 at 11:52:57AM -0700, Mark Klein wrote:
> Richard, it appears by the ChangeLog that you made the original changes
> to pa32-regs.h and pa64-regs.h.

Not true.  What you see is the rename from CLASS_CANNOT_CHANGE_SIZE
to CLASS_CANNOT_CHANGE_MODE.


r~

Re: Unaligned double

[Mark Klein]

Joern Renneck wrote:

 > The way the insn number changes hints that this is probably done by
 > combine.

This was unoptimized code and I never saw combine_instructions called
in my test.

 > pa32-regs.h is rather odd in that it defines CLASS_CANNOT_CHANGE_MODE
 > as NO_REGS and then goes on to define CLASS_CANNOT_CHANGE_MODE_P to
 > reject size-changing mode changes. The latter is made ineffective by
 > the former.

I changed my pa32-regs.h such that CLASS_CANNOT_CHANGE_MODE is (FP_REGS)
as is done in pa64-regs.h and that resolves this issue. However, I'm not
sure what else it might break on PA 1.1 platforms as I can't test there.

Richard, it appears by the ChangeLog that you made the original changes
to pa32-regs.h and pa64-regs.h. Was there a specific reason that the
macro was NO_REGS in pa32 and FP_REGS in pa64?

Regards,


M.


--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--