Question about integer_asm_op()

[Jim Wilson]

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