On Wed, 12 Jun 2013, Richard Biener wrote:
On Tue, Jun 11, 2013 at 9:44 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
On Tue, 11 Jun 2013, Jeff Law wrote:
On 06/09/13 13:43, Marc Glisse wrote:
Hello,
just adapting yet another function so it also works with vectors.
It seemed convenient to add a new macro. The name sucks (it doesn't
match the semantics of INTEGRAL_TYPE_P), but I didn't want to name it
INTEGER_SCALAR_OR_VECTOR_CONSTANT_P and didn't have any good idea for a
short name.
I'd just use a long name. I can easily see someone getting easily not
being aware that INTEGRAL_CST_P returns true for vectors and as a result
doing something inappropriate.
INTEGER_CST_OR_VECTOR_INTEGER_TYPE_P?
Having TYPE in there seems confusing, and
INTEGER_SCALAR_OR_VECTOR_CONSTANT_P is at least one character shorter ;-)
Oh, you probably meant INTEGER_CST_OR_VECTOR_INTEGER_CST_P?
Compacting could give INT_OR_VECINT_CST_P (or INTVEC instead of VECINT, I
don't know which order sounds best).
I don't really mind the name, so if you want
INTEGER_CST_OR_VECTOR_INTEGER_CST_P that's ok with me.
How about just adding VECTOR_INTEGER_CST_P and using
TREE_CODE (x) == INTEGER_CST || VECTOR_INTEGER_CST_P (x)
in the code?
That's a bit heavy, but I can live with that.
I suppose it's explicitely not allowing complex integer constants?
Hmm... Thanks, I keep forgetting complex :-(
Testing for CONSTANT_CLASS_P seems sufficient here. Some transformations
also seem valid for complex, and the others are already restricted by the
fact that they involve operators like AND or XOR, or because we exit early
for FLOAT_TYPE_P and FIXED_POINT_TYPE_P. I'll test that (no new macro for
now then).
--
Marc Glisse
