Re: [GSoC] support for literals

[Richard Biener <richard dot guenther at gmail dot com>]

On Sun, Jul 27, 2014 at 10:05 PM, Prathamesh Kulkarni
<bilbotheelffriend@gmail.com> wrote:
> Hi,
>     I was wondering if it would be a good idea to have the following syntax
> for literals:
> (type val) ?
> type would be one of the tree-codes representing cst types like
> INTEGER_CST, REAL_CST, etc.
>
> eg:
> (negate (integer_cst 3))
>
> would be equivalent to the following:
> (negate INTEGER_CST_P@0)
> if (TREE_INT_CST_LOW (@0) == 3)
> { .. }
>
> Also possibly provide a short-hand for some literals
> like integer and floating point, so just writing
> 3 would be short-hand for (integer_cst 3) ?

Hmm.  If then I'd rather support literals "literally", thus

  (negate 3)

because the type is always available from the context.

I also think literal constants are more useful in the transform
context...

But really I'd like to defer this for now - literals would be
treated quite specially (for example should '0' be emitted
as integer_zerop () handling many types or should it be
treated as integral-type-only?).  Should we only allow
a specific set of literals (-1, 0, 1)?  How do we write
literals of complex or vector type?

So yes, literals would be nice (sometimes), but universal
handling of literals is hard.

How would people feel about only handling a very small set of literals
in a subset of all contexts (only in matching or only in code-generation)?

> Many patterns from [1] have integral constants to match.
> eg: (a >> 2) >=3 -> a >= (3 << 2)
> so this could be written as:
> (gte (rshift @0 2) 3)
> (gte @0 (lshift 3 2))
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753

I'm quite sure this bug wants more general treatment of these
patterns, not only handling the special combinations of constants...

Richard.

>
> Thanks,
> Prathamesh