This is the mail archive of the gcc@gcc.gnu.org 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: bundle boundaries in ia64 assembly output?


On Jan 24, 2005, at 08:29, Jan Beulich wrote:
There was a discussion started at
http://gcc.gnu.org/ml/gcc/2003-12/msg00821.html and leading to the
idea of adding bundle boundaries (not just bundle types as is still
getting done) to the assembly output. Searching gcc-patches, however,
doesn't even seem to locate a rejected or never approved patch, and
hence I wonder whether implementation of this was ever attempted.

We did try this approach, and inserted proper markers for the begin and end of bundles. However, for our goal of being able to use the Intel assembler this was not enough. GCC puts labels, mainly for EH, in arbitrary locations. The published Intel assembly syntax requires use of instruction tags instead. These tags have a different syntax.

Fixing this issue would require changes outside of the IA-64 specific
files, as EH symbols and tags get added too late. Because of these
issues and the impression no one else was interested in having
GCC produce assembly in the format documented by Intel, we are now
considering porting GNU as to IVMS after all.

The reason I'm asking is not because of using ias as the consumer of
the assembly, but instead to have an additional level of verification of
the generated output; with a recently submitted patch (don't recall by
whom) I noticed that bundling in .s and .o differed, and it took me a
while to realize that this was because an insn had a wrong attribute,
making the compiler schedule it on the wrong unit. Such problems go by
unnoticed because without bundle boundaries the assembler silently
splits in two bundles what was intended to go into one.

I think it would be good to have the explicit bundling, as I distrust
"smart" assemblers. Ideally, GCC would directly output object files,
and optionally object file listings for debugging purposes. Failing that,
generating unambiguous assembly code is a reasonable alternative.


I'll see if I can dig up the patch for the explicit bundle markers, if
you're interested.

-Geert


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