* Question about integer_asm_op()
@ 2003-04-25 21:22 John Lu
2003-04-25 22:16 ` Richard Henderson
0 siblings, 1 reply; 4+ messages in thread
From: John Lu @ 2003-04-25 21:22 UTC (permalink / raw)
To: gcc
Hi,
In varasm.c, function integer_asm_op(size, aligned_p) has the following
comment.
/* Return the assembler directive for creating a given kind of integer
object. SIZE is the number of bytes in the object and ALIGNED_P
indicates whether it is known to be aligned.
... */
Then it has the following code:
if (aligned_p)
ops = &targetm.asm_out.aligned_op;
else
ops = &targetm.asm_out.unaligned_op;
I was wondering if the arms of the if-else should be swapped.
The way I interpret the comment, "aligned_p" guarantees that
an integer is already aligned. In the code, it seems to be
used as a request -- please generate assembly to align the integer.
Thanks,
John Lu
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about integer_asm_op()
2003-04-25 21:22 Question about integer_asm_op() John Lu
@ 2003-04-25 22:16 ` Richard Henderson
0 siblings, 0 replies; 4+ messages in thread
From: Richard Henderson @ 2003-04-25 22:16 UTC (permalink / raw)
To: John Lu; +Cc: gcc
On Fri, Apr 25, 2003 at 02:41:54PM -0500, John Lu wrote:
> The way I interpret the comment, "aligned_p" guarantees that
> an integer is already aligned. In the code, it seems to be
> used as a request -- please generate assembly to align the integer.
What gives you that impression? Usage looks like
assemble_align (POINTER_SIZE);
assemble_integer (symbol, POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE, 1);
r~
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about integer_asm_op()
2003-04-25 23:42 John Lu
@ 2003-04-27 6:10 ` Jim Wilson
0 siblings, 0 replies; 4+ messages in thread
From: Jim Wilson @ 2003-04-27 6:10 UTC (permalink / raw)
To: John Lu; +Cc: gcc
It would be easier to help you if you reported an actual problem. An
actual problem is something like gcc crashes for this input, or gives
incorrect output for that input. Instead, you are making guesses, and
then presenting an analysis based on that guess. This makes it hard for
us to figure out what your actual problem is. Please report the actual
problem.
I think you are confused on two points: what alignment means, and what
the purpose of targetm.asm_out.aligned_op and unaligned_op is.
John Lu wrote:
> aligned_p = (align >= MIN (size * BITS_PER_UNIT, BIGGEST_ALIGNMENT));
Note that in the degenerate case where align == BIGGEST_ALIGNMENT,
align_p is true.
> In my particular case, I have a pointer of size==2, BITS_PER_UNIT==16,
> align==16, and BIGGEST_ALIGNMENT==16. Since BITS_PER_UNIT==BIGGEST_ALIGNMENT,
> I would expect alignment to never be necessary, but in this case
> aligned_p=1.
This is the degnerate case, where align == BIGGEST_ALIGNMENT, thus
align_p is true. For alignment purposes, it makes no difference whether
align_p is true for false, you get the same result. However, it does
matter to the assembler.
Most assembly languages have a standard set of directives for aligned
data. These are used for data that have normal alignment, or alignment
larger than normal. There is a second set of directives for unaligned
data, i.e. data with smaller than normal alignment. These directives
cause the assembler/linker to create special relocations and/or emit
special code. These directives are less efficient, and thus we only
emit them in special cases. In the degenerate case, we must emit the
normal directives. Common examples of this assembler syntax is
.word/.uaword and .word/.2byte.
In your case, we are correctly using an aligned directive. There can be
a problem only if the assembler has normal data directives that give
larger alignment than BIGGEST_ALIGNMENT. This would be surprising. I'd
say that either the compiler or assembler is broken, since they don't
agree on BIGGEST_ALIGNMENT. If you can work around this by using
different assembler directives, that might be best. These assembler
directives are target configurable. Asking us to emit unaligned
directives here to avoid the problem is a mistake. We can't do that.
Jim
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about integer_asm_op()
@ 2003-04-25 23:42 John Lu
2003-04-27 6:10 ` Jim Wilson
0 siblings, 1 reply; 4+ messages in thread
From: John Lu @ 2003-04-25 23:42 UTC (permalink / raw)
To: gcc
I interpreted align_p as a guarantee of an alignment because of
my reading of the comment on line 1903
object. SIZE is the number of bytes in the object and ALIGNED_P
indicates whether it is known to be aligned. Return NULL if the
and because it is calculated in assemble_integer() as:
aligned_p = (align >= MIN (size * BITS_PER_UNIT, BIGGEST_ALIGNMENT));
In this calculation, I could only make sense of it if "align" was an
alignment that the compiler could already guarantee. Then if "align"
is greater than the size of the object or greater than the maximum
possible alignment required by the system, the compiler can state
that alignment is already satisfied.
I initially thought "align" in this calculation was a requested alignment.
But I could not understand why alignment is required only if the
requested alignment is greater than the size of the object or greater
than the largest alignment possibly required by the system.
In my particular case, I have a pointer of size==2, BITS_PER_UNIT==16,
align==16, and BIGGEST_ALIGNMENT==16. Since BITS_PER_UNIT==BIGGEST_ALIGNMENT,
I would expect alignment to never be necessary, but in this case
aligned_p=1.
Hope this is clear. Thanks for your help.
John Lu
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-04-27 1:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-25 21:22 Question about integer_asm_op() John Lu
2003-04-25 22:16 ` Richard Henderson
2003-04-25 23:42 John Lu
2003-04-27 6:10 ` Jim Wilson
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).