This is the mail archive of the gcc-patches@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: hook-ize ASM_FILE_START, take two


Hans-Peter Nilsson <hp@bitrange.com> writes:
> On Sun, 22 Jun 2003, Zack Weinberg wrote:
>> That is unfortunate: the x86 back end consistently uses the style
>>
>> <TAB>mnemonic<TAB>operand1,<SPACE>operand2
>
> Oh, I see.  This is somewhat recent.  gcc-2.95.3 didn't do that;
> I tacked #NO_APP on top of code for a trivial function "int a
> (int b) {return b + 42;}" and just had to remove some extraneous
> spaces in pseudos.

It came in with the x86 backend rewrite in the 2.96 timeframe.

> Well, they seem to have changed in one direction, so supposedly
> they could change back since there's a reason.  Unless of course
> the first change was actually due to a real reason, like some
> other assembler that dislikes space in place of the second TAB.
> If not, maybe people could accept the reason that "a b,c" *is*
> more readable than "a\tb, c".

Well, I don't agree with that, so I doubt a consensus can be reached
on grounds of readability.  The 1-2% speedup is a more compelling
argument.  

Unexpected reformatting is not so great - it interferes with
reproducibility.  And the amount of work that would have to be done in
asm_fprintf is nontrivial, it might eat up the performance gain.  I am
tempted to script a conversion of i386.md and then measure overall
performance improvement.

zw


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