public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).