On Aug 24, 2007, at 8:37 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour,
and it
helps programmers and helps existing code. Who does it hurt to
permit
this extension? Who does it help to forbid this extension?
Aren't builtins the designated way to access processor-specific
features like this? Why does there have to be C operators for
obscure features like this?
A fair question, but we've already decided to support vector + vector
and such operations, and we've decided that that is one valid way to
generate vector instructions. That decision may itself have been a
mistake. But once we accept that decision, then, given that we know
that the processor supports bitwise-or on floating point values, using
a instruction different from that for bitwise-or on integer values,
then it is fair to ask why we don't support vector | vector for
floating point vectors.
My personal opinion is that the grammar and type rules of the
language should be defined independently of the target. "+" is
allowed on all generic vectors for all targets. Allowing &^| to be
used on FP vectors on some targets but not others seems extremely
inconsistent (generic vectors are supposed to provide some amount of
portability after all). Allowing these operators on all targets also
seems strange to me, but is a better solution than allowing them on
some targets but not others.
I consider pollution of the IR to be a significant problem. If you
allow this, you suddenly have tree nodes and RTL nodes for logical
operations that have to handle operands that are FP vectors. I
imagine that this will result in either 1) subtle bugs in various
transformations that work on these or 2) special case code to handle
this in various cases, spread through the optimizer.
-Chris
