This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Introduce abi_word_mode
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Geoffrey Keating <geoffk at apple dot com>, Andreas Krebbel <Andreas dot Krebbel at de dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 09 Oct 2006 15:47:21 -0700
- Subject: Re: [PATCH] Introduce abi_word_mode
- References: <200610092237.k99MbRhg001420@d12av02.megacenter.de.ibm.com>
Ulrich Weigand wrote:
(I apologize for duplicate messages, I used a broken mailer ...)
Mark Mitchell <email@example.com> wrote on 10/09/2006 11:15:44 PM:
So, are we converging towards telling Andreas that there is no way to do
what he wishes? In other words, are going to declare that attribute
((mode (word))) is not something that back ends can configure
independently of BITS_PER_WORD, and that, therefore, if you have 32-bit
code involving that type, that this binary code cannot be recompiled
without change to use 64-bit registers?
That would be quite unfortunate. I do hope we can get to a common
understanding of what attribute ((mode (word))) means that does not
preclude this type of optimization, that is not only important for
s390, but also for rs6000 and possibly even for x86_64 ...
I think the optimization is just fine -- but I think that it might be
that some code (namely, code that uses attribute ((mode (word)))) would
need to change to take advantage of the optimization. (For example, it
could use SImode instead, or just "int".) In other words, I think it's
too strong a statement to say that not allowing the change to mode(word)
prevents the optimization. You could even add a warning for uses of
mode(word) to help catch problems when recompiling programs; it would be
a mechanical change.
What do you think of my current proposal as outlined in my replies to
Richard and Ian?
Frankly, I think it adds more complexity where we should have less. I'd
rather we move away from this feature entirely than that we introduce
(650) 331-3385 x713