* LO_SUM memrefs offsettable ?
@ 1999-01-21 3:07 Michael Hayes
1999-01-21 6:58 ` Jeffrey A Law
1999-01-31 23:58 ` Michael Hayes
0 siblings, 2 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-21 3:07 UTC (permalink / raw)
To: egcs
I've noticed from perusing some of the backends that there is
confusion over whether LO_SUM memrefs are offsettable.
Can anyone categorically state what the case is?
offsettable_address_p considers that LO_SUM memrefs are offsettable
yet operand_subword calls plus_constant instead of
plus_constant_for_output. This has the effect of generating
addresses of the form (PLUS (LO_SUM (REG) (SYMBOL_REF)) (CONST_INT)
instead of (LO_SUM (REG) (CONST (SYMBOL_REF) (CONST_INT))).
Now I can see that there is a problem when considering an offsettable
LO_SUM memref at the end of a data page, since the data page register
may require updating as well. Is this the main stumbling block with
the use of a LO_SUM/HIGH insn pair?
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 3:07 LO_SUM memrefs offsettable ? Michael Hayes
@ 1999-01-21 6:58 ` Jeffrey A Law
1999-01-21 11:04 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Michael Hayes
1 sibling, 2 replies; 44+ messages in thread
From: Jeffrey A Law @ 1999-01-21 6:58 UTC (permalink / raw)
To: Michael Hayes; +Cc: egcs
In message < 13991.2128.712970.417769@ongaonga.elec.canterbury.ac.nz >you write
:
>
> I've noticed from perusing some of the backends that there is
> confusion over whether LO_SUM memrefs are offsettable.
> Can anyone categorically state what the case is?
Consider a machine where HI does something like
HI reg = (symref & 0xffff0000)
LO_SUM reg += (symref & 0xffff)
If you're going to add a constant to the LO_SUM, then you need to find its
associated HIGH part and add the constant to the HIGH part too. Else you
can get inconsistencies. Consider the adddress 0xffff.
> offsettable_address_p considers that LO_SUM memrefs are offsettable
It probably shouldn't.
> yet operand_subword calls plus_constant instead of
> plus_constant_for_output. This has the effect of generating
> addresses of the form (PLUS (LO_SUM (REG) (SYMBOL_REF)) (CONST_INT)
> instead of (LO_SUM (REG) (CONST (SYMBOL_REF) (CONST_INT))).
Ah, yes, that's the only way to make it work.
jeff
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 6:58 ` Jeffrey A Law
@ 1999-01-21 11:04 ` Michael Hayes
1999-01-21 14:09 ` Bill Currie
1999-01-31 23:58 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
1 sibling, 2 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-21 11:04 UTC (permalink / raw)
To: law; +Cc: Michael Hayes, egcs
Jeffrey A Law writes:
> If you're going to add a constant to the LO_SUM, then you need to find its
> associated HIGH part and add the constant to the HIGH part too. Else you
> can get inconsistencies. Consider the adddress 0xffff.
OK, that's what I thought was the problem. (Life without boundary
conditions would be so much simpler :-) I'll submit some modified docs.
Rather than adding the constant to the associated HIGH part, I would
have thought that been safer to emit a new load of the modified HIGH
part?
> > offsettable_address_p considers that LO_SUM memrefs are offsettable
> It probably shouldn't.
Do any ports rely on this behaviour or does every port using LO_SUM
have to have a work around for this?
> > yet operand_subword calls plus_constant instead of
> > plus_constant_for_output. This has the effect of generating
> > addresses of the form (PLUS (LO_SUM (REG) (SYMBOL_REF)) (CONST_INT)
> > instead of (LO_SUM (REG) (CONST (SYMBOL_REF) (CONST_INT))).
> Ah, yes, that's the only way to make it work.
So what's the mechanism employed to make this work? Any good examples
to look at?
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 11:04 ` Michael Hayes
@ 1999-01-21 14:09 ` Bill Currie
1999-01-21 15:01 ` Jeffrey A Law
1999-01-31 23:58 ` Bill Currie
1999-01-31 23:58 ` Michael Hayes
1 sibling, 2 replies; 44+ messages in thread
From: Bill Currie @ 1999-01-21 14:09 UTC (permalink / raw)
To: Michael Hayes; +Cc: law, egcs
Michael Hayes wrote:
>
> Jeffrey A Law writes:
>
> > If you're going to add a constant to the LO_SUM, then you need to find its
> > associated HIGH part and add the constant to the HIGH part too. Else you
> > can get inconsistencies. Consider the adddress 0xffff.
>
> OK, that's what I thought was the problem. (Life without boundary
> conditions would be so much simpler :-)
:) They got me too.
> I'll submit some modified docs.
That would be good. There are some nasty traps with lo_sum/high (such
as these) that porters realy should be warned about.
> Rather than adding the constant to the associated HIGH part, I would
> have thought that been safer to emit a new load of the modified HIGH
> part?
That's what I did for my i860 work (not submitted):, so yes, *I* believe
loading a new HIGH part is safer
> > > offsettable_address_p considers that LO_SUM memrefs are offsettable
> > It probably shouldn't.
>
> Do any ports rely on this behaviour or does every port using LO_SUM
> have to have a work around for this?
>
> > > yet operand_subword calls plus_constant instead of
> > > plus_constant_for_output. This has the effect of generating
> > > addresses of the form (PLUS (LO_SUM (REG) (SYMBOL_REF)) (CONST_INT)
> > > instead of (LO_SUM (REG) (CONST (SYMBOL_REF) (CONST_INT))).
> > Ah, yes, that's the only way to make it work.
>
> So what's the mechanism employed to make this work? Any good examples
> to look at?
What I did is to completely load the symbol ref into a register and
offset that. it was the only safe way I could think of due to those
boundary conditions.
Bill
--
Leave others their otherness
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 14:09 ` Bill Currie
@ 1999-01-21 15:01 ` Jeffrey A Law
1999-01-21 17:28 ` Richard Henderson
` (3 more replies)
1999-01-31 23:58 ` Bill Currie
1 sibling, 4 replies; 44+ messages in thread
From: Jeffrey A Law @ 1999-01-21 15:01 UTC (permalink / raw)
To: Bill Currie; +Cc: Michael Hayes, egcs
In message < 36A7A610.75041BDD@tssc.co.nz >you write:
> > I'll submit some modified docs.
>
> That would be good. There are some nasty traps with lo_sum/high (such
> as these) that porters realy should be warned about.
Yup. Please do. I don't think the HI/LO_SUM stuff has been updated since
1990 or so.
> > > > offsettable_address_p considers that LO_SUM memrefs are offsettabl
> e
> > > It probably shouldn't.
> >
> > Do any ports rely on this behaviour or does every port using LO_SUM
> > have to have a work around for this?
Well, not sure. There are some ports where adding a small constant to the
LO_SUM will work as expected -- the PA being one.
Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
offsets directly to the LO_SUM and not lose.
We do that in some cases, but I don't know if it depends on that particular
behavior from reload or if the PA port handles it internally. It's been a
long time since I looked at that code :-)
Actually, since HIGH & LO_SUM don't specify their size, I suspect that the
port has to handle everything internally since there's no way to describe
to the machine independent part of the compiler when the overlap is safe.
jeff
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 15:01 ` Jeffrey A Law
@ 1999-01-21 17:28 ` Richard Henderson
1999-01-21 17:42 ` Michael Hayes
` (2 more replies)
1999-01-22 7:10 ` Joern Rennecke
` (2 subsequent siblings)
3 siblings, 3 replies; 44+ messages in thread
From: Richard Henderson @ 1999-01-21 17:28 UTC (permalink / raw)
To: law, Bill Currie; +Cc: Michael Hayes, egcs
On Thu, Jan 21, 1999 at 03:53:34PM -0700, Jeffrey A Law wrote:
> Well, not sure. There are some ports where adding a small constant to the
> LO_SUM will work as expected -- the PA being one.
>
> Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
> upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
> offsets directly to the LO_SUM and not lose.
Sparc as well. HIGH is the top 22, and the field containing
the LO_SUM is 13 bits.
> Actually, since HIGH & LO_SUM don't specify their size, I suspect that the
> port has to handle everything internally since there's no way to describe
> to the machine independent part of the compiler when the overlap is safe.
Indeed.
r~
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 17:28 ` Richard Henderson
@ 1999-01-21 17:42 ` Michael Hayes
1999-01-21 18:06 ` Richard Henderson
` (2 more replies)
1999-01-24 2:48 ` Michael Hayes
1999-01-31 23:58 ` Richard Henderson
2 siblings, 3 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-21 17:42 UTC (permalink / raw)
To: Richard Henderson; +Cc: law, Bill Currie, Michael Hayes, egcs
Richard Henderson writes:
> > Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
> > upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
> > offsets directly to the LO_SUM and not lose.
>
> Sparc as well. HIGH is the top 22, and the field containing
> the LO_SUM is 13 bits.
OK, for these machines where there is an overlap, a LO_SUM address can
be considered offsettable. In this case shouldn't operand_subword
call plus_constant_for_output?
I imagine that there is no overlap for the MIPS as is the case with
the C4x (which is 16 + 16 bits).
> > Actually, since HIGH & LO_SUM don't specify their size, I suspect that the
> > port has to handle everything internally since there's no way to describe
> > to the machine independent part of the compiler when the overlap is safe.
Maybe we should have some macros to specify these sizes; it would be
useful for documentation and could be used to make
offsettable_address_p do the right thing.
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 17:42 ` Michael Hayes
@ 1999-01-21 18:06 ` Richard Henderson
1999-01-31 23:58 ` Richard Henderson
1999-01-22 7:17 ` Joern Rennecke
1999-01-31 23:58 ` Michael Hayes
2 siblings, 1 reply; 44+ messages in thread
From: Richard Henderson @ 1999-01-21 18:06 UTC (permalink / raw)
To: Michael Hayes, Richard Henderson; +Cc: law, Bill Currie, egcs
On Fri, Jan 22, 1999 at 02:45:35PM +1300, Michael Hayes wrote:
> OK, for these machines where there is an overlap, a LO_SUM address can
> be considered offsettable. In this case shouldn't operand_subword
> call plus_constant_for_output?
I actually think we should do wrt the lo_sum handling whatever is Right
for mips and c4x -- ie don't generate (plus (lo_sum reg sym) const).
The only difference is that for sparc and pa it is legal to match
up a (high sym) and (lo_sum reg (const (plus sym const))) assuming
const is small enough.
> Maybe we should have some macros to specify these sizes; it would be
> useful for documentation and could be used to make
> offsettable_address_p do the right thing.
I'd rather you didn't. As free time allows, I've got an inventive
use for high+lo_sum pairs on Alpha that bear little relation its
usage elsewhere.
There's quite a bit of linker relaxation that can usefully happen
on 64-bit PIC parts, and to do it I need load/use information
extracted from the compiler's data flow. To that end, I intend to
use high and lo_sum as addressing tags for later perusal.
Maybe it doesn't matter -- if my use is considered non-offsettable,
things may work out just fine.
r~
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 15:01 ` Jeffrey A Law
1999-01-21 17:28 ` Richard Henderson
@ 1999-01-22 7:10 ` Joern Rennecke
1999-01-31 23:58 ` Joern Rennecke
1999-01-24 15:02 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
3 siblings, 1 reply; 44+ messages in thread
From: Joern Rennecke @ 1999-01-22 7:10 UTC (permalink / raw)
To: law; +Cc: bcurrie, m.hayes, egcs
> Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
> upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
> offsets directly to the LO_SUM and not lose.
AFAIK there's also overlap for the sparc. A lack of overlap can probably
be considered a design problem of the architecture, since it disables a
lot of cse opportunities.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 17:42 ` Michael Hayes
1999-01-21 18:06 ` Richard Henderson
@ 1999-01-22 7:17 ` Joern Rennecke
1999-01-31 23:58 ` Joern Rennecke
1999-01-31 23:58 ` Michael Hayes
2 siblings, 1 reply; 44+ messages in thread
From: Joern Rennecke @ 1999-01-22 7:17 UTC (permalink / raw)
To: Michael Hayes; +Cc: rth, law, bcurrie, m.hayes, egcs
> Maybe we should have some macros to specify these sizes; it would be
> useful for documentation and could be used to make
> offsettable_address_p do the right thing.
Yes, that would be useful - this would also allow to use larger offsets
that what an offsetable memref usally implies.
For example, we migt have a struct that is something smaller than 2 KB.
On a Pa or sparc, we can load the HIGH part of the struct's address in
a register and then use LO_SUM to address any member of the struct.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 17:28 ` Richard Henderson
1999-01-21 17:42 ` Michael Hayes
@ 1999-01-24 2:48 ` Michael Hayes
1999-01-24 3:04 ` Jeffrey A Law
` (3 more replies)
1999-01-31 23:58 ` Richard Henderson
2 siblings, 4 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-24 2:48 UTC (permalink / raw)
To: Richard Henderson; +Cc: law, Bill Currie, Michael Hayes, egcs
Richard Henderson writes:
> Sparc as well. HIGH is the top 22, and the field containing
> the LO_SUM is 13 bits.
OK, I've got a rather sparse matrix. Can anyone help fill in the
gaps?
TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
c4x 16 16 0
m32r 0
m88k
mips
pa 21 14
rs6000
sparc 22 13
v850
Here MAX_OFFSET is the maximum number of bytes that can be added to
the LO_SUM memref without having to update the associated HIGH part.
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 2:48 ` Michael Hayes
@ 1999-01-24 3:04 ` Jeffrey A Law
1999-01-25 9:19 ` Manfred Hollstein
1999-01-31 23:58 ` Jeffrey A Law
1999-01-24 9:38 ` David Edelsohn
` (2 subsequent siblings)
3 siblings, 2 replies; 44+ messages in thread
From: Jeffrey A Law @ 1999-01-24 3:04 UTC (permalink / raw)
To: Michael Hayes; +Cc: Richard Henderson, Bill Currie, egcs
In message < 13994.63599.400327.836906@ongaonga.elec.canterbury.ac.nz >you writ
e:
> Richard Henderson writes:
> > Sparc as well. HIGH is the top 22, and the field containing
> > the LO_SUM is 13 bits.
>
> OK, I've got a rather sparse matrix. Can anyone help fill in the
> gaps?
>
>
> TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
>
> c4x 16 16 0
> m32r 0
> m88k
> mips
> pa 21 14
> rs6000
> sparc 22 13
> v850
v850 is 16/16/0
mips is 16/16/0
jeff
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 2:48 ` Michael Hayes
1999-01-24 3:04 ` Jeffrey A Law
@ 1999-01-24 9:38 ` David Edelsohn
1999-01-31 23:58 ` David Edelsohn
1999-01-25 14:02 ` Bill Currie
1999-01-31 23:58 ` Michael Hayes
3 siblings, 1 reply; 44+ messages in thread
From: David Edelsohn @ 1999-01-24 9:38 UTC (permalink / raw)
To: Michael Hayes; +Cc: egcs
>>>>> Michael Hayes writes:
Michael> TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
Michael> c4x 16 16 0
Michael> m32r 0
Michael> m88k
Michael> mips
Michael> pa 21 14
Michael> rs6000
Michael> sparc 22 13
Michael> v850
rs6000/powerpc is 16/16
David
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 15:01 ` Jeffrey A Law
1999-01-21 17:28 ` Richard Henderson
1999-01-22 7:10 ` Joern Rennecke
@ 1999-01-24 15:02 ` Michael Hayes
1999-01-24 23:18 ` Jeffrey A Law
1999-01-31 23:58 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
3 siblings, 2 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-24 15:02 UTC (permalink / raw)
To: law; +Cc: Bill Currie, Michael Hayes, egcs
Jeffrey A Law writes:
> Well, not sure. There are some ports where adding a small constant to the
> LO_SUM will work as expected -- the PA being one.
>
> Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
> upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
> offsets directly to the LO_SUM and not lose.
How does the PA (and SPARC) combine the two quantities?
Obviously, the concept of a simple addition as implied by LO_SUM
is not correct on these processors.
If I understand the paging mechanism, we have:
PAGE_SIZE = 2 ^ (BITS_PER_LO_SUM)
PAGE_SEPARATION = 2 ^ (BITS_PER_ADDRESS - BITS_PER_HIGH)
and thus the maximum offset we can achieve without having to modify
the data page register is:
MAX_LO_SUM_OFFSET = PAGE_SIZE - PAGE_SEPARATION.
Thus my table becomes (which shows why most backends complain about
adddress_offsetable_p ;-)
TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_LO_SUM_OFFSET
c4x 16 16 0
m32r 0
m88k 0?
mips 16 16 0
pa 21 14 14336
rs6000 16 16 0
sparc 22 13 7168
v850 16 16 0
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 15:02 ` Michael Hayes
@ 1999-01-24 23:18 ` Jeffrey A Law
1999-01-25 0:11 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Michael Hayes
1 sibling, 2 replies; 44+ messages in thread
From: Jeffrey A Law @ 1999-01-24 23:18 UTC (permalink / raw)
To: Michael Hayes; +Cc: Bill Currie, egcs
In message < 13995.39413.956926.359943@ongaonga.elec.canterbury.ac.nz >you writ
e:
> How does the PA (and SPARC) combine the two quantities?
I think we compute the address as:
(high (plus (symbol_ref) (rounded_constant))
(lo_sum (tmpreg) (plus (symbol_ref) (constant))
References with nearby addresses will tend to have the same rounded offset,
so they emit the same high insn. Which is then caught by cse.
I believe the maximum offset for the PA is +-8K.
jeff
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 23:18 ` Jeffrey A Law
@ 1999-01-25 0:11 ` Michael Hayes
1999-01-25 21:07 ` Richard Henderson
1999-01-31 23:58 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
1 sibling, 2 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-25 0:11 UTC (permalink / raw)
To: law; +Cc: Michael Hayes, Bill Currie, egcs
Jeffrey A Law writes:
> I think we compute the address as:
>
> (high (plus (symbol_ref) (rounded_constant))
> (lo_sum (tmpreg) (plus (symbol_ref) (constant))
Ah, I overlooked the possibility of rounding the high part of the
address. That's a good idea. Does the sparc does this as well? If
not, it will be harder to describe. I was hoping to describe the
HIGH/LO_SUM behaviour with two parameters which could be used to
determine the maximum offset.
> I believe the maximum offset for the PA is +-8K.
This makes sense. If the sparc used similar rounding for the HIGH
part, I imagine the maximum offset would be +-4K.
Actually, I would have thought that the maximum offset we could use
would be a bit less due to quantization of the HIGH part.
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 3:04 ` Jeffrey A Law
@ 1999-01-25 9:19 ` Manfred Hollstein
1999-01-31 23:58 ` Manfred Hollstein
1999-01-31 23:58 ` Jeffrey A Law
1 sibling, 1 reply; 44+ messages in thread
From: Manfred Hollstein @ 1999-01-25 9:19 UTC (permalink / raw)
To: m.hayes; +Cc: law, rth, bcurrie, egcs
On Sun, 24 January 1999, 03:56:53, law@hurl.cygnus.com wrote:
>
> In message < 13994.63599.400327.836906@ongaonga.elec.canterbury.ac.nz >you writ
> e:
> > Richard Henderson writes:
> > > Sparc as well. HIGH is the top 22, and the field containing
> > > the LO_SUM is 13 bits.
> >
> > OK, I've got a rather sparse matrix. Can anyone help fill in the
> > gaps?
> >
> >
> > TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
> >
> > c4x 16 16 0
> > m32r 0
> > m88k
> > mips
> > pa 21 14
> > rs6000
> > sparc 22 13
> > v850
> v850 is 16/16/0
> mips is 16/16/0
m88k is 16/16/0, too.
manfred
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 2:48 ` Michael Hayes
1999-01-24 3:04 ` Jeffrey A Law
1999-01-24 9:38 ` David Edelsohn
@ 1999-01-25 14:02 ` Bill Currie
1999-01-31 23:58 ` Bill Currie
1999-01-31 23:58 ` Michael Hayes
3 siblings, 1 reply; 44+ messages in thread
From: Bill Currie @ 1999-01-25 14:02 UTC (permalink / raw)
To: Michael Hayes; +Cc: Richard Henderson, law, egcs
Michael Hayes wrote:
>
> Richard Henderson writes:
> > Sparc as well. HIGH is the top 22, and the field containing
> > the LO_SUM is 13 bits.
>
> OK, I've got a rather sparse matrix. Can anyone help fill in the
> gaps?
>
> TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
i860 16 16 0
--
Leave others their otherness
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-25 0:11 ` Michael Hayes
@ 1999-01-25 21:07 ` Richard Henderson
1999-01-26 1:28 ` Michael Hayes
` (2 more replies)
1999-01-31 23:58 ` Michael Hayes
1 sibling, 3 replies; 44+ messages in thread
From: Richard Henderson @ 1999-01-25 21:07 UTC (permalink / raw)
To: Michael Hayes, law; +Cc: Bill Currie, egcs
On Mon, Jan 25, 1999 at 09:14:06PM +1300, Michael Hayes wrote:
> Ah, I overlooked the possibility of rounding the high part of the
> address. That's a good idea. Does the sparc does this as well?
Sparc actually traditionally emits
sethi %hi(foo), %g1
or %g1, %lo(foo), %g1
Where %lo() only sets the low 10 bits. This can obviously be
replaced with an `add' when one wants to muck with other bits.
Hmm.. come to think of it, I'm not sure most sparc assemblers
would do the right thing with
add %g1, %lo(foo)+4000, %g1
Ack. I now see that there's no relocation to describe it
either. :-(
Sigh. Modify the sparc entry to 22/10/0.
r~
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-25 21:07 ` Richard Henderson
@ 1999-01-26 1:28 ` Michael Hayes
1999-01-31 23:58 ` Michael Hayes
1999-01-26 10:18 ` Joern Rennecke
1999-01-31 23:58 ` Richard Henderson
2 siblings, 1 reply; 44+ messages in thread
From: Michael Hayes @ 1999-01-26 1:28 UTC (permalink / raw)
To: Richard Henderson; +Cc: Michael Hayes, law, Bill Currie, egcs
Richard Henderson writes:
> Hmm.. come to think of it, I'm not sure most sparc assemblers
> would do the right thing with
>
> add %g1, %lo(foo)+4000, %g1
>
> Ack. I now see that there's no relocation to describe it
> either. :-(
>
> Sigh. Modify the sparc entry to 22/10/0.
So the winner is the PA, by a mile.
TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_LO_SUM_OFFSET
c4x 16 16 0
i860 16 16 0
m32r 16? 16? 0
m88k 16 16 0
mips 16 16 0
pa 21 14 +-8192*
rs6000 16 16 0
sparc 22 10 0
v850 16 16 0
[* I think to be safe that this would have to be 1024 bytes smaller]
I wonder if we should collect information like this somewhere
to aid folks who are starting new ports or new optimisations?
This could be a nice little project for someone ;-)
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-25 21:07 ` Richard Henderson
1999-01-26 1:28 ` Michael Hayes
@ 1999-01-26 10:18 ` Joern Rennecke
1999-01-27 0:26 ` Richard Henderson
1999-01-31 23:58 ` Joern Rennecke
1999-01-31 23:58 ` Richard Henderson
2 siblings, 2 replies; 44+ messages in thread
From: Joern Rennecke @ 1999-01-26 10:18 UTC (permalink / raw)
To: rth; +Cc: m.hayes, law, bcurrie, egcs
> Hmm.. come to think of it, I'm not sure most sparc assemblers
> would do the right thing with
>
> add %g1, %lo(foo)+4000, %g1
>
> Ack. I now see that there's no relocation to describe it
> either. :-(
>
> Sigh. Modify the sparc entry to 22/10/0.
Well, we should be able to extend gas / gld to support such a relocation,
and then allow to configure gcc to assume that this replocation is
available (or make it a run-time option).
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-26 10:18 ` Joern Rennecke
@ 1999-01-27 0:26 ` Richard Henderson
1999-01-31 23:58 ` Richard Henderson
1999-01-31 23:58 ` Joern Rennecke
1 sibling, 1 reply; 44+ messages in thread
From: Richard Henderson @ 1999-01-27 0:26 UTC (permalink / raw)
To: Joern Rennecke, rth; +Cc: m.hayes, law, bcurrie, egcs
On Tue, Jan 26, 1999 at 06:17:18PM +0000, Joern Rennecke wrote:
> Well, we should be able to extend gas / gld to support such a relocation,
> and then allow to configure gcc to assume that this replocation is
> available (or make it a run-time option).
Eh, I feel it'd be a hack at best. Plus there the small
matter of binary compatibility.
r~
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-26 1:28 ` Michael Hayes
@ 1999-01-31 23:58 ` Michael Hayes
0 siblings, 0 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-31 23:58 UTC (permalink / raw)
To: Richard Henderson; +Cc: Michael Hayes, law, Bill Currie, egcs
Richard Henderson writes:
> Hmm.. come to think of it, I'm not sure most sparc assemblers
> would do the right thing with
>
> add %g1, %lo(foo)+4000, %g1
>
> Ack. I now see that there's no relocation to describe it
> either. :-(
>
> Sigh. Modify the sparc entry to 22/10/0.
So the winner is the PA, by a mile.
TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_LO_SUM_OFFSET
c4x 16 16 0
i860 16 16 0
m32r 16? 16? 0
m88k 16 16 0
mips 16 16 0
pa 21 14 +-8192*
rs6000 16 16 0
sparc 22 10 0
v850 16 16 0
[* I think to be safe that this would have to be 1024 bytes smaller]
I wonder if we should collect information like this somewhere
to aid folks who are starting new ports or new optimisations?
This could be a nice little project for someone ;-)
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-25 9:19 ` Manfred Hollstein
@ 1999-01-31 23:58 ` Manfred Hollstein
0 siblings, 0 replies; 44+ messages in thread
From: Manfred Hollstein @ 1999-01-31 23:58 UTC (permalink / raw)
To: m.hayes; +Cc: law, rth, bcurrie, egcs
On Sun, 24 January 1999, 03:56:53, law@hurl.cygnus.com wrote:
>
> In message < 13994.63599.400327.836906@ongaonga.elec.canterbury.ac.nz >you writ
> e:
> > Richard Henderson writes:
> > > Sparc as well. HIGH is the top 22, and the field containing
> > > the LO_SUM is 13 bits.
> >
> > OK, I've got a rather sparse matrix. Can anyone help fill in the
> > gaps?
> >
> >
> > TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
> >
> > c4x 16 16 0
> > m32r 0
> > m88k
> > mips
> > pa 21 14
> > rs6000
> > sparc 22 13
> > v850
> v850 is 16/16/0
> mips is 16/16/0
m88k is 16/16/0, too.
manfred
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-25 21:07 ` Richard Henderson
1999-01-26 1:28 ` Michael Hayes
1999-01-26 10:18 ` Joern Rennecke
@ 1999-01-31 23:58 ` Richard Henderson
2 siblings, 0 replies; 44+ messages in thread
From: Richard Henderson @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes, law; +Cc: Bill Currie, egcs
On Mon, Jan 25, 1999 at 09:14:06PM +1300, Michael Hayes wrote:
> Ah, I overlooked the possibility of rounding the high part of the
> address. That's a good idea. Does the sparc does this as well?
Sparc actually traditionally emits
sethi %hi(foo), %g1
or %g1, %lo(foo), %g1
Where %lo() only sets the low 10 bits. This can obviously be
replaced with an `add' when one wants to muck with other bits.
Hmm.. come to think of it, I'm not sure most sparc assemblers
would do the right thing with
add %g1, %lo(foo)+4000, %g1
Ack. I now see that there's no relocation to describe it
either. :-(
Sigh. Modify the sparc entry to 22/10/0.
r~
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-27 0:26 ` Richard Henderson
@ 1999-01-31 23:58 ` Richard Henderson
0 siblings, 0 replies; 44+ messages in thread
From: Richard Henderson @ 1999-01-31 23:58 UTC (permalink / raw)
To: Joern Rennecke, rth; +Cc: m.hayes, law, bcurrie, egcs
On Tue, Jan 26, 1999 at 06:17:18PM +0000, Joern Rennecke wrote:
> Well, we should be able to extend gas / gld to support such a relocation,
> and then allow to configure gcc to assume that this replocation is
> available (or make it a run-time option).
Eh, I feel it'd be a hack at best. Plus there the small
matter of binary compatibility.
r~
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 23:18 ` Jeffrey A Law
1999-01-25 0:11 ` Michael Hayes
@ 1999-01-31 23:58 ` Jeffrey A Law
1 sibling, 0 replies; 44+ messages in thread
From: Jeffrey A Law @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes; +Cc: Bill Currie, egcs
In message < 13995.39413.956926.359943@ongaonga.elec.canterbury.ac.nz >you writ
e:
> How does the PA (and SPARC) combine the two quantities?
I think we compute the address as:
(high (plus (symbol_ref) (rounded_constant))
(lo_sum (tmpreg) (plus (symbol_ref) (constant))
References with nearby addresses will tend to have the same rounded offset,
so they emit the same high insn. Which is then caught by cse.
I believe the maximum offset for the PA is +-8K.
jeff
^ permalink raw reply [flat|nested] 44+ messages in thread
* LO_SUM memrefs offsettable ?
1999-01-21 3:07 LO_SUM memrefs offsettable ? Michael Hayes
1999-01-21 6:58 ` Jeffrey A Law
@ 1999-01-31 23:58 ` Michael Hayes
1 sibling, 0 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-31 23:58 UTC (permalink / raw)
To: egcs
I've noticed from perusing some of the backends that there is
confusion over whether LO_SUM memrefs are offsettable.
Can anyone categorically state what the case is?
offsettable_address_p considers that LO_SUM memrefs are offsettable
yet operand_subword calls plus_constant instead of
plus_constant_for_output. This has the effect of generating
addresses of the form (PLUS (LO_SUM (REG) (SYMBOL_REF)) (CONST_INT)
instead of (LO_SUM (REG) (CONST (SYMBOL_REF) (CONST_INT))).
Now I can see that there is a problem when considering an offsettable
LO_SUM memref at the end of a data page, since the data page register
may require updating as well. Is this the main stumbling block with
the use of a LO_SUM/HIGH insn pair?
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-22 7:10 ` Joern Rennecke
@ 1999-01-31 23:58 ` Joern Rennecke
0 siblings, 0 replies; 44+ messages in thread
From: Joern Rennecke @ 1999-01-31 23:58 UTC (permalink / raw)
To: law; +Cc: bcurrie, m.hayes, egcs
> Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
> upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
> offsets directly to the LO_SUM and not lose.
AFAIK there's also overlap for the sparc. A lack of overlap can probably
be considered a design problem of the architecture, since it disables a
lot of cse opportunities.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-22 7:17 ` Joern Rennecke
@ 1999-01-31 23:58 ` Joern Rennecke
0 siblings, 0 replies; 44+ messages in thread
From: Joern Rennecke @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes; +Cc: rth, law, bcurrie, m.hayes, egcs
> Maybe we should have some macros to specify these sizes; it would be
> useful for documentation and could be used to make
> offsettable_address_p do the right thing.
Yes, that would be useful - this would also allow to use larger offsets
that what an offsetable memref usally implies.
For example, we migt have a struct that is something smaller than 2 KB.
On a Pa or sparc, we can load the HIGH part of the struct's address in
a register and then use LO_SUM to address any member of the struct.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 6:58 ` Jeffrey A Law
1999-01-21 11:04 ` Michael Hayes
@ 1999-01-31 23:58 ` Jeffrey A Law
1 sibling, 0 replies; 44+ messages in thread
From: Jeffrey A Law @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes; +Cc: egcs
In message < 13991.2128.712970.417769@ongaonga.elec.canterbury.ac.nz >you write
:
>
> I've noticed from perusing some of the backends that there is
> confusion over whether LO_SUM memrefs are offsettable.
> Can anyone categorically state what the case is?
Consider a machine where HI does something like
HI reg = (symref & 0xffff0000)
LO_SUM reg += (symref & 0xffff)
If you're going to add a constant to the LO_SUM, then you need to find its
associated HIGH part and add the constant to the HIGH part too. Else you
can get inconsistencies. Consider the adddress 0xffff.
> offsettable_address_p considers that LO_SUM memrefs are offsettable
It probably shouldn't.
> yet operand_subword calls plus_constant instead of
> plus_constant_for_output. This has the effect of generating
> addresses of the form (PLUS (LO_SUM (REG) (SYMBOL_REF)) (CONST_INT)
> instead of (LO_SUM (REG) (CONST (SYMBOL_REF) (CONST_INT))).
Ah, yes, that's the only way to make it work.
jeff
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 3:04 ` Jeffrey A Law
1999-01-25 9:19 ` Manfred Hollstein
@ 1999-01-31 23:58 ` Jeffrey A Law
1 sibling, 0 replies; 44+ messages in thread
From: Jeffrey A Law @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes; +Cc: Richard Henderson, Bill Currie, egcs
In message < 13994.63599.400327.836906@ongaonga.elec.canterbury.ac.nz >you writ
e:
> Richard Henderson writes:
> > Sparc as well. HIGH is the top 22, and the field containing
> > the LO_SUM is 13 bits.
>
> OK, I've got a rather sparse matrix. Can anyone help fill in the
> gaps?
>
>
> TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
>
> c4x 16 16 0
> m32r 0
> m88k
> mips
> pa 21 14
> rs6000
> sparc 22 13
> v850
v850 is 16/16/0
mips is 16/16/0
jeff
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 2:48 ` Michael Hayes
` (2 preceding siblings ...)
1999-01-25 14:02 ` Bill Currie
@ 1999-01-31 23:58 ` Michael Hayes
3 siblings, 0 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-31 23:58 UTC (permalink / raw)
To: Richard Henderson; +Cc: law, Bill Currie, Michael Hayes, egcs
Richard Henderson writes:
> Sparc as well. HIGH is the top 22, and the field containing
> the LO_SUM is 13 bits.
OK, I've got a rather sparse matrix. Can anyone help fill in the
gaps?
TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
c4x 16 16 0
m32r 0
m88k
mips
pa 21 14
rs6000
sparc 22 13
v850
Here MAX_OFFSET is the maximum number of bytes that can be added to
the LO_SUM memref without having to update the associated HIGH part.
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 15:02 ` Michael Hayes
1999-01-24 23:18 ` Jeffrey A Law
@ 1999-01-31 23:58 ` Michael Hayes
1 sibling, 0 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-31 23:58 UTC (permalink / raw)
To: law; +Cc: Bill Currie, Michael Hayes, egcs
Jeffrey A Law writes:
> Well, not sure. There are some ports where adding a small constant to the
> LO_SUM will work as expected -- the PA being one.
>
> Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
> upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
> offsets directly to the LO_SUM and not lose.
How does the PA (and SPARC) combine the two quantities?
Obviously, the concept of a simple addition as implied by LO_SUM
is not correct on these processors.
If I understand the paging mechanism, we have:
PAGE_SIZE = 2 ^ (BITS_PER_LO_SUM)
PAGE_SEPARATION = 2 ^ (BITS_PER_ADDRESS - BITS_PER_HIGH)
and thus the maximum offset we can achieve without having to modify
the data page register is:
MAX_LO_SUM_OFFSET = PAGE_SIZE - PAGE_SEPARATION.
Thus my table becomes (which shows why most backends complain about
adddress_offsetable_p ;-)
TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_LO_SUM_OFFSET
c4x 16 16 0
m32r 0
m88k 0?
mips 16 16 0
pa 21 14 14336
rs6000 16 16 0
sparc 22 13 7168
v850 16 16 0
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 14:09 ` Bill Currie
1999-01-21 15:01 ` Jeffrey A Law
@ 1999-01-31 23:58 ` Bill Currie
1 sibling, 0 replies; 44+ messages in thread
From: Bill Currie @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes; +Cc: law, egcs
Michael Hayes wrote:
>
> Jeffrey A Law writes:
>
> > If you're going to add a constant to the LO_SUM, then you need to find its
> > associated HIGH part and add the constant to the HIGH part too. Else you
> > can get inconsistencies. Consider the adddress 0xffff.
>
> OK, that's what I thought was the problem. (Life without boundary
> conditions would be so much simpler :-)
:) They got me too.
> I'll submit some modified docs.
That would be good. There are some nasty traps with lo_sum/high (such
as these) that porters realy should be warned about.
> Rather than adding the constant to the associated HIGH part, I would
> have thought that been safer to emit a new load of the modified HIGH
> part?
That's what I did for my i860 work (not submitted):, so yes, *I* believe
loading a new HIGH part is safer
> > > offsettable_address_p considers that LO_SUM memrefs are offsettable
> > It probably shouldn't.
>
> Do any ports rely on this behaviour or does every port using LO_SUM
> have to have a work around for this?
>
> > > yet operand_subword calls plus_constant instead of
> > > plus_constant_for_output. This has the effect of generating
> > > addresses of the form (PLUS (LO_SUM (REG) (SYMBOL_REF)) (CONST_INT)
> > > instead of (LO_SUM (REG) (CONST (SYMBOL_REF) (CONST_INT))).
> > Ah, yes, that's the only way to make it work.
>
> So what's the mechanism employed to make this work? Any good examples
> to look at?
What I did is to completely load the symbol ref into a register and
offset that. it was the only safe way I could think of due to those
boundary conditions.
Bill
--
Leave others their otherness
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 18:06 ` Richard Henderson
@ 1999-01-31 23:58 ` Richard Henderson
0 siblings, 0 replies; 44+ messages in thread
From: Richard Henderson @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes, Richard Henderson; +Cc: law, Bill Currie, egcs
On Fri, Jan 22, 1999 at 02:45:35PM +1300, Michael Hayes wrote:
> OK, for these machines where there is an overlap, a LO_SUM address can
> be considered offsettable. In this case shouldn't operand_subword
> call plus_constant_for_output?
I actually think we should do wrt the lo_sum handling whatever is Right
for mips and c4x -- ie don't generate (plus (lo_sum reg sym) const).
The only difference is that for sparc and pa it is legal to match
up a (high sym) and (lo_sum reg (const (plus sym const))) assuming
const is small enough.
> Maybe we should have some macros to specify these sizes; it would be
> useful for documentation and could be used to make
> offsettable_address_p do the right thing.
I'd rather you didn't. As free time allows, I've got an inventive
use for high+lo_sum pairs on Alpha that bear little relation its
usage elsewhere.
There's quite a bit of linker relaxation that can usefully happen
on 64-bit PIC parts, and to do it I need load/use information
extracted from the compiler's data flow. To that end, I intend to
use high and lo_sum as addressing tags for later perusal.
Maybe it doesn't matter -- if my use is considered non-offsettable,
things may work out just fine.
r~
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 17:42 ` Michael Hayes
1999-01-21 18:06 ` Richard Henderson
1999-01-22 7:17 ` Joern Rennecke
@ 1999-01-31 23:58 ` Michael Hayes
2 siblings, 0 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-31 23:58 UTC (permalink / raw)
To: Richard Henderson; +Cc: law, Bill Currie, Michael Hayes, egcs
Richard Henderson writes:
> > Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
> > upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
> > offsets directly to the LO_SUM and not lose.
>
> Sparc as well. HIGH is the top 22, and the field containing
> the LO_SUM is 13 bits.
OK, for these machines where there is an overlap, a LO_SUM address can
be considered offsettable. In this case shouldn't operand_subword
call plus_constant_for_output?
I imagine that there is no overlap for the MIPS as is the case with
the C4x (which is 16 + 16 bits).
> > Actually, since HIGH & LO_SUM don't specify their size, I suspect that the
> > port has to handle everything internally since there's no way to describe
> > to the machine independent part of the compiler when the overlap is safe.
Maybe we should have some macros to specify these sizes; it would be
useful for documentation and could be used to make
offsettable_address_p do the right thing.
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 15:01 ` Jeffrey A Law
` (2 preceding siblings ...)
1999-01-24 15:02 ` Michael Hayes
@ 1999-01-31 23:58 ` Jeffrey A Law
3 siblings, 0 replies; 44+ messages in thread
From: Jeffrey A Law @ 1999-01-31 23:58 UTC (permalink / raw)
To: Bill Currie; +Cc: Michael Hayes, egcs
In message < 36A7A610.75041BDD@tssc.co.nz >you write:
> > I'll submit some modified docs.
>
> That would be good. There are some nasty traps with lo_sum/high (such
> as these) that porters realy should be warned about.
Yup. Please do. I don't think the HI/LO_SUM stuff has been updated since
1990 or so.
> > > > offsettable_address_p considers that LO_SUM memrefs are offsettabl
> e
> > > It probably shouldn't.
> >
> > Do any ports rely on this behaviour or does every port using LO_SUM
> > have to have a work around for this?
Well, not sure. There are some ports where adding a small constant to the
LO_SUM will work as expected -- the PA being one.
Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
offsets directly to the LO_SUM and not lose.
We do that in some cases, but I don't know if it depends on that particular
behavior from reload or if the PA port handles it internally. It's been a
long time since I looked at that code :-)
Actually, since HIGH & LO_SUM don't specify their size, I suspect that the
port has to handle everything internally since there's no way to describe
to the machine independent part of the compiler when the overlap is safe.
jeff
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-25 14:02 ` Bill Currie
@ 1999-01-31 23:58 ` Bill Currie
0 siblings, 0 replies; 44+ messages in thread
From: Bill Currie @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes; +Cc: Richard Henderson, law, egcs
Michael Hayes wrote:
>
> Richard Henderson writes:
> > Sparc as well. HIGH is the top 22, and the field containing
> > the LO_SUM is 13 bits.
>
> OK, I've got a rather sparse matrix. Can anyone help fill in the
> gaps?
>
> TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
i860 16 16 0
--
Leave others their otherness
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-25 0:11 ` Michael Hayes
1999-01-25 21:07 ` Richard Henderson
@ 1999-01-31 23:58 ` Michael Hayes
1 sibling, 0 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-31 23:58 UTC (permalink / raw)
To: law; +Cc: Michael Hayes, Bill Currie, egcs
Jeffrey A Law writes:
> I think we compute the address as:
>
> (high (plus (symbol_ref) (rounded_constant))
> (lo_sum (tmpreg) (plus (symbol_ref) (constant))
Ah, I overlooked the possibility of rounding the high part of the
address. That's a good idea. Does the sparc does this as well? If
not, it will be harder to describe. I was hoping to describe the
HIGH/LO_SUM behaviour with two parameters which could be used to
determine the maximum offset.
> I believe the maximum offset for the PA is +-8K.
This makes sense. If the sparc used similar rounding for the HIGH
part, I imagine the maximum offset would be +-4K.
Actually, I would have thought that the maximum offset we could use
would be a bit less due to quantization of the HIGH part.
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 11:04 ` Michael Hayes
1999-01-21 14:09 ` Bill Currie
@ 1999-01-31 23:58 ` Michael Hayes
1 sibling, 0 replies; 44+ messages in thread
From: Michael Hayes @ 1999-01-31 23:58 UTC (permalink / raw)
To: law; +Cc: Michael Hayes, egcs
Jeffrey A Law writes:
> If you're going to add a constant to the LO_SUM, then you need to find its
> associated HIGH part and add the constant to the HIGH part too. Else you
> can get inconsistencies. Consider the adddress 0xffff.
OK, that's what I thought was the problem. (Life without boundary
conditions would be so much simpler :-) I'll submit some modified docs.
Rather than adding the constant to the associated HIGH part, I would
have thought that been safer to emit a new load of the modified HIGH
part?
> > offsettable_address_p considers that LO_SUM memrefs are offsettable
> It probably shouldn't.
Do any ports rely on this behaviour or does every port using LO_SUM
have to have a work around for this?
> > yet operand_subword calls plus_constant instead of
> > plus_constant_for_output. This has the effect of generating
> > addresses of the form (PLUS (LO_SUM (REG) (SYMBOL_REF)) (CONST_INT)
> > instead of (LO_SUM (REG) (CONST (SYMBOL_REF) (CONST_INT))).
> Ah, yes, that's the only way to make it work.
So what's the mechanism employed to make this work? Any good examples
to look at?
Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-21 17:28 ` Richard Henderson
1999-01-21 17:42 ` Michael Hayes
1999-01-24 2:48 ` Michael Hayes
@ 1999-01-31 23:58 ` Richard Henderson
2 siblings, 0 replies; 44+ messages in thread
From: Richard Henderson @ 1999-01-31 23:58 UTC (permalink / raw)
To: law, Bill Currie; +Cc: Michael Hayes, egcs
On Thu, Jan 21, 1999 at 03:53:34PM -0700, Jeffrey A Law wrote:
> Well, not sure. There are some ports where adding a small constant to the
> LO_SUM will work as expected -- the PA being one.
>
> Basically, there's a few bits of overlap on the PA. The "HIGH" sets the
> upper 21 bits, the LO_SUM sets the low 14 bits. Thus we can add small
> offsets directly to the LO_SUM and not lose.
Sparc as well. HIGH is the top 22, and the field containing
the LO_SUM is 13 bits.
> Actually, since HIGH & LO_SUM don't specify their size, I suspect that the
> port has to handle everything internally since there's no way to describe
> to the machine independent part of the compiler when the overlap is safe.
Indeed.
r~
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-26 10:18 ` Joern Rennecke
1999-01-27 0:26 ` Richard Henderson
@ 1999-01-31 23:58 ` Joern Rennecke
1 sibling, 0 replies; 44+ messages in thread
From: Joern Rennecke @ 1999-01-31 23:58 UTC (permalink / raw)
To: rth; +Cc: m.hayes, law, bcurrie, egcs
> Hmm.. come to think of it, I'm not sure most sparc assemblers
> would do the right thing with
>
> add %g1, %lo(foo)+4000, %g1
>
> Ack. I now see that there's no relocation to describe it
> either. :-(
>
> Sigh. Modify the sparc entry to 22/10/0.
Well, we should be able to extend gas / gld to support such a relocation,
and then allow to configure gcc to assume that this replocation is
available (or make it a run-time option).
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LO_SUM memrefs offsettable ?
1999-01-24 9:38 ` David Edelsohn
@ 1999-01-31 23:58 ` David Edelsohn
0 siblings, 0 replies; 44+ messages in thread
From: David Edelsohn @ 1999-01-31 23:58 UTC (permalink / raw)
To: Michael Hayes; +Cc: egcs
>>>>> Michael Hayes writes:
Michael> TARGET BITS_PER_HIGH BITS_PER_LO_SUM MAX_OFFSET
Michael> c4x 16 16 0
Michael> m32r 0
Michael> m88k
Michael> mips
Michael> pa 21 14
Michael> rs6000
Michael> sparc 22 13
Michael> v850
rs6000/powerpc is 16/16
David
^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~1999-01-31 23:58 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-01-21 3:07 LO_SUM memrefs offsettable ? Michael Hayes
1999-01-21 6:58 ` Jeffrey A Law
1999-01-21 11:04 ` Michael Hayes
1999-01-21 14:09 ` Bill Currie
1999-01-21 15:01 ` Jeffrey A Law
1999-01-21 17:28 ` Richard Henderson
1999-01-21 17:42 ` Michael Hayes
1999-01-21 18:06 ` Richard Henderson
1999-01-31 23:58 ` Richard Henderson
1999-01-22 7:17 ` Joern Rennecke
1999-01-31 23:58 ` Joern Rennecke
1999-01-31 23:58 ` Michael Hayes
1999-01-24 2:48 ` Michael Hayes
1999-01-24 3:04 ` Jeffrey A Law
1999-01-25 9:19 ` Manfred Hollstein
1999-01-31 23:58 ` Manfred Hollstein
1999-01-31 23:58 ` Jeffrey A Law
1999-01-24 9:38 ` David Edelsohn
1999-01-31 23:58 ` David Edelsohn
1999-01-25 14:02 ` Bill Currie
1999-01-31 23:58 ` Bill Currie
1999-01-31 23:58 ` Michael Hayes
1999-01-31 23:58 ` Richard Henderson
1999-01-22 7:10 ` Joern Rennecke
1999-01-31 23:58 ` Joern Rennecke
1999-01-24 15:02 ` Michael Hayes
1999-01-24 23:18 ` Jeffrey A Law
1999-01-25 0:11 ` Michael Hayes
1999-01-25 21:07 ` Richard Henderson
1999-01-26 1:28 ` Michael Hayes
1999-01-31 23:58 ` Michael Hayes
1999-01-26 10:18 ` Joern Rennecke
1999-01-27 0:26 ` Richard Henderson
1999-01-31 23:58 ` Richard Henderson
1999-01-31 23:58 ` Joern Rennecke
1999-01-31 23:58 ` Richard Henderson
1999-01-31 23:58 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Bill Currie
1999-01-31 23:58 ` Michael Hayes
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Michael Hayes
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).