This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Revised patch to remove integer output macros

Richard Henderson <> writes:
> In general, this looks really good.  The only real mistake I think
> is that you should _always_ call the hook first, and that if the
> target does support a simple string for emitting data, then it 
> should be present.  I.e.

I wrote it that way originally, but changed my mind ;).

I guess the question is: should target independent code be allowed to
access the string ops directly?  The dwarf2 code is written like that at
the moment, and it's certainly nicer (for example) to have all the bytes
of a sleb or uleb on the same line.

If target independent code _can_ access the ops directly, then I think
assemble_integer should too.  Otherwise we'd have a situation where the
string ops would be used in preference to the hook in some places and
the hook would be used first in others.

If target independent code _can't_ access the ops directly, then I agree
that it's better to chain the hooks.  In that case, though, there needs
to be some way of controlling whether a newline is written, and (more
complicated) a way of writing several objects on the same line.

I started on the second alternative, but went for the first in the end.
I thought defining assemble_integer_with_op would make it simple for
target-specific code to use a string op in the usual way.

More importantly, though...

>    static bool
>    arc_assemble_integer (x, size, aligned_p)
>         rtx x;
>         unsigned int size;
>         int aligned_p;
>    {
>      if (size == UNITS_PER_WORD && aligned_p
>          && ((GET_CODE (x) == SYMBOL_REF && SYMBOL_REF_FLAG (x))
> 	     || GET_CODE (x) == LABEL_REF))
>        {
>          fputs ("\t.word\t%st(", asm_out_file);
>          output_addr_const (asm_out_file, x);
>          fputs (")\n", asm_out_file);
>          return true;
>        }
>      return default_assemble_integer (x, size, aligned_p);  
>    }
> This would clean up quite a lot of the tricky bits that you
> encountered, particularly on rs6000.

...I got the impression this stuff wasn't really correct anyway.

The avr port always uses ".word" for aligned word-sized objects, so it
really ought to able use TARGET_ASM_ALIGNED_SI_OP.  The fact that
certain labels need to wrapped in %st() seems to have more to do
with output_addr_const() than the fact that we're writing an aligned
word.  The same applies to arc, arm, ia64 & pa.

Running this code on an unpatched ia64 compiler:

    void foo (void);
    struct s { char c; void (*f) (void); };
    struct t { char c; void (*f) (void); } __attribute__ ((packed));
    struct s s = { 1, foo };
    struct t t = { 1, foo };

I get [snipped down a bit]:

            data1	1
            .skip	7
            data8	@fptr(foo#)
            data1	1

Should it really do that?  Is @fptr() really only for aligned objects,
or is it simply that we've been able to get away with assuming it is?
(I don't know, I'm not familiar with the ia64.)

The problem hits hardest in the pa case because it has two different
word sizes.  The pseudo-op for each size is always the same, it's just
that we sometimes need to print "P%" in front of a label.

I thought perhaps we need (yet another!) target hook to control how the
object itself is written.  Perhaps a wrapper to output_addr_const(),
or something.  Then most of this complexity would go away.  And when
it does, there seems less reason to stop target-independent code
accessing the strings directly.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]