On 07/27/2015 09:47 PM, Trevor Saunders wrote:
On Mon, Jul 27, 2015 at 11:06:58AM +0200, Richard Biener wrote:
On Sat, Jul 25, 2015 at 4:37 AM, <tbsaunde+...@tbsaunde.org> wrote:
From: Trevor Saunders <tbsaunde+...@tbsaunde.org>
* config/arc/arc.h, config/bfin/bfin.h, config/frv/frv.h,
config/ia64/ia64-protos.h, config/ia64/ia64.c, config/ia64/ia64.h,
config/lm32/lm32.h, config/mep/mep.h, config/mmix/mmix.h,
config/rs6000/rs6000.c, config/rs6000/xcoff.h, config/spu/spu.h,
config/visium/visium.h, defaults.h: Define ASM_OUTPUT_LABEL to
the name of a function.
* output.h (default_output_label): New prototype.
* varasm.c (default_output_label): New function.
* vmsdbgout.c: Include tm_p.h.
* xcoffout.c: Likewise.
Just a general remark - the GCC output machinery is known to be slow,
adding indirect calls might be not the very best idea without refactoring
some of it.
ah, I wasn't aware of that. On the other hand some of these hooks seem
to generally be big so the call over head might not matter that much. I
suppose if this is something we really care about we might want to
consider pushing the libgas project farther so we can avoid all this
text formatting all together.
They're definitely slow, but I've always considered that overhead as in
the noise relative to what it takes to run through the optimizer passes.
I'm tentatively supported of libgas, but I have concerns as well. I've
been burned by (for example) vendor assemblers which didn't have a means
(assembler directives) to correctly handle certain programs. The
vendor's compiler didn't have the problem because it just blasted .o
files and didn't pass them through the assembler. I'd hate to see us
repeating those mistakes.
Jeff
