Re: Help restricting args of an intrinsic function

Re: Help restricting args of an intrinsic function

[Etienne Lorrain]

On Monday, February 2, 2004, at 04:35 PM, Daniel Jacobowitz wrote: 
>  const int ci = 5;
>  int a1[ci];
> will not compile, because ci is not an integral constant-expression. 

Mike Stump wrote:
> Does anyone know why the above isn't supported in C? Certainly
> the obviousness of it escapes me. My inclination is to fix the
> standard, not the compiler.

  In C, the keyword "const" means "not modifyed by the C", but it has to
 be a real variable - in case it is modifyed by the program loader or
 linker (for instance in assembler) before the C program starts.
  The C standard should have defined the real constant:
inline const int size_of_array = 5;
  but someone forgot.
  I could also have replaced a lot of #define and #if/#ifdef by C
 constructs, like "inline const struct { ...; } configuration;".

  A dreamer...


	

	
		
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! 
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Re: Help restricting args of an intrinsic function

[Gabriel Dos Reis]

Mike Stump <mrs@apple.com> writes:

| it.  Also, telling users that their code doesn't work in C, but works
| in C++ in this one case, is, uhm, pedantic.

Wow.  Isn't what the C lanaguage specification had elected to?

Sorry, couldn't resist.

-- Gaby, returning to work

Re: Help restricting args of an intrinsic function

[Mike Stump]

On Monday, February 2, 2004, at 04:35 PM, Daniel Jacobowitz wrote:
> If you read Richard's reply, he says that will already work - in C++.  
> In C,
>
>   const int ci = 5;
>   int a1[ci];
>
> will not compile, because ci is not an integral constant-expression.

I know.  But, one of the main reasons why we are introducing builtins 
is to be able to compile code from another compiler, Code Warrior.  We 
are doing this so that users have an easy code migration.  They allow 
it.  Also, telling users that their code doesn't work in C, but works 
in C++ in this one case, is, uhm, pedantic.

Does anyone know why the above isn't supported in C?  Certainly the 
obviousness of it escapes me.  My inclination is to fix the standard, 
not the compiler.

> If Syd is trying to make that work in C/ObjC, as opposed to C++, some
> serious surgery may be involved.

I'm envisioning 6 lines of code.  I can't fathom what could possible 
require major surgery.

Re: Help restricting args of an intrinsic function

[Richard Henderson]

On Mon, Feb 02, 2004 at 04:29:31PM -0800, Syd Polk wrote:
> This is the problem I am trying to solve. Line 9 should compile as 
> well. Our competition can do it. We cannot. I am trying to make it 
> work.

The rules for these intrinsics should be absolutely crystal clear.  
The way to make that happen is to fall back on language from the
standard.  The appropriate term is "integer constant expression".

QED.


r~

Re: Help restricting args of an intrinsic function

[Daniel Jacobowitz]

On Mon, Feb 02, 2004 at 04:31:27PM -0800, Mike Stump wrote:
> On Monday, February 2, 2004, at 03:45 PM, Joe Buck wrote:
> >So issue a warning, and make the warning suppressible.  If you don't,
> >you'll then be in the position of telling people to use #define instead
> >of const,
> 
> ?  I don't see that that follows.  Syd intends on making const int i = 
> 5 work.  If he does that, then there is not need to tell people to use 
> #define instead of const int i = 5.
> 
> >and you'll saddle us with a huge stream of additional bugs
> >(any time the compiler changes in such a way that an expression that
> >used to be simplified to a constant at -O0 isn't, we get a bug report).
> 
> Again, I don't see that this follows:
> 
> const int ci = 5;
> class A {
> public:
>   static const int sci = 5;
>   static char a1[sci];
> } a;
> 
> char A::a1[sci];
> 
> int a1[ci];
> int a2[A::sci];
> 
> is valid code that already must work, and work is defined to be knowing 
> that size of the arrays at compile time.
> 
> Syd needs nothing more.  Since this is already implemented, already 
> works, and already is maintained, I don't see this as a maintenance 
> burden.  The only issue is how best to hook into it.

If you read Richard's reply, he says that will already work - in C++.  In C,

  const int ci = 5;
  int a1[ci];

will not compile, because ci is not an integral constant-expression.

If Syd is trying to make that work in C/ObjC, as opposed to C++, some
serious surgery may be involved.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Help restricting args of an intrinsic function

[Mike Stump]

On Monday, February 2, 2004, at 03:45 PM, Joe Buck wrote:
> So issue a warning, and make the warning suppressible.  If you don't,
> you'll then be in the position of telling people to use #define instead
> of const,

?  I don't see that that follows.  Syd intends on making const int i = 
5 work.  If he does that, then there is not need to tell people to use 
#define instead of const int i = 5.

> and you'll saddle us with a huge stream of additional bugs
> (any time the compiler changes in such a way that an expression that
> used to be simplified to a constant at -O0 isn't, we get a bug report).

Again, I don't see that this follows:

const int ci = 5;
class A {
public:
   static const int sci = 5;
   static char a1[sci];
} a;

char A::a1[sci];

int a1[ci];
int a2[A::sci];

is valid code that already must work, and work is defined to be knowing 
that size of the arrays at compile time.

Syd needs nothing more.  Since this is already implemented, already 
works, and already is maintained, I don't see this as a maintenance 
burden.  The only issue is how best to hook into it.

Also, Syd has a wonderfully extensive testsuite.  It just won't be 
possible to break this for more than 24 hours without Geoff's tester 
complaining.

Also, I failed to mention that generating a warning and having the 
fallback code would be lots more work and be error prone, it doesn't 
_just_ violate the users expectations.

Re: Help restricting args of an intrinsic function

[Syd Polk]

On Feb 2, 2004, at 3:56 PM, Richard Henderson wrote:

> On Mon, Feb 02, 2004 at 03:44:11PM -0800, Syd Polk wrote:
>> I don't think that we will need the pointer case. We will need the
>> following:
>>
>> - hard-coded integers
>> - const int variables
>> - static const int members in C++
>> - enums
>
> Point the second should be for C++ only, where it has integer
> constant expression semantics.
>
> At which point, you're in EXACTLY the same situation that already
> exists for x86 and altivec intrinsics.  This is not a new problem,
> and it does not need a new solution.
>

#include "altivec.h"

int main(int argc, const *argv[])
{
   const int shift = 3;
   const vector int foo;

   vec_splat (foo, 5);
   vec_splat (foo, shift);
}

produces:

[stravinsky:FSF/TOT-intrinsics/gcc] spolk% ./xgcc -B . -fPIC -maltivec 
/tmp/altivec.c /tmp/altivec.c: In function `main':
/tmp/altivec.c:9: error: argument 2 must be a 5-bit unsigned literal

This is the problem I am trying to solve. Line 9 should compile as 
well. Our competition can do it. We cannot. I am trying to make it 
work.


>
> r~
>
>
Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: Help restricting args of an intrinsic function

[Richard Henderson]

On Mon, Feb 02, 2004 at 03:44:11PM -0800, Syd Polk wrote:
> I don't think that we will need the pointer case. We will need the 
> following:
> 
> - hard-coded integers
> - const int variables
> - static const int members in C++
> - enums

Point the second should be for C++ only, where it has integer
constant expression semantics.

At which point, you're in EXACTLY the same situation that already
exists for x86 and altivec intrinsics.  This is not a new problem,
and it does not need a new solution.


r~

Re: Help restricting args of an intrinsic function

[Joe Buck]

I wrote:
> > Who says that exactly one instruction must be emitted with the
> > optimizer off?  It seems to me that it would suffice to have the
> > builtin function emit the one instruction in the case where the mask
> > arguments, after any optimization, are constant, and otherwise emit
> > whatever code is needed to compute the correct result (or simply emit
> > a call to a library function).

On Mon, Feb 02, 2004 at 03:37:15PM -0800, Mike Stump wrote:
> This violates the users expectations.
> 
> The _point_ of having builtins for single machine instructions is so 
> that the generated code will use them (or something better).  Tweaking 
> a builtin to generate an external lib call or 5 instructions instead of 
> using that one machine instruction isn't, uhm, winning.

So issue a warning, and make the warning suppressible.  If you don't,
you'll then be in the position of telling people to use #define instead
of const, and you'll saddle us with a huge stream of additional bugs
(any time the compiler changes in such a way that an expression that
used to be simplified to a constant at -O0 isn't, we get a bug report).

Re: Help restricting args of an intrinsic function

[Syd Polk]

On Feb 2, 2004, at 11:58 AM, Mike Stump wrote:
> On Saturday, January 31, 2004, at 07:25 AM, Diego Novillo wrote:
>> Syd seems to be looking for anything that the compiler can prove is a
>> constant.
>
> Ok, I'll buy that, but I don't think we want anything that can ever be 
> turned off via an -O style option, or anything that is (or can be) 
> machine dependent.
>

What we support needs to work at -O0.

>> Powerful != expensive.  Why are you considering such a simple data 
>> flow
>> problem a non-starter?
>
> We don't want to offer something that only compiles code on some 
> machine or only compiles code with certain optimization settings.
>
> The pointer case may be just beyond what we want to work.
>

I don't think that we will need the pointer case. We will need the 
following:

- hard-coded integers
- const int variables
- static const int members in C++
- enums

Anything else does not work in the competing compiler, either.

Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: Help restricting args of an intrinsic function

[Mike Stump]

On Monday, February 2, 2004, at 03:26 PM, Joe Buck wrote:
> On Fri, Jan 30, 2004 at 07:59:34PM -0800, Mike Stump wrote:
>> On Friday, January 30, 2004, at 05:38  PM, Diego Novillo wrote:
>>> Yes, that's fine.  Here's what tree-ssa emits after the tree
>>> optimization passes for the test cases you mentioned.
>>
>> So, does your scheme work when the optimizer is off (-O0)?
>>
>> If not, why would that be a solution?
>
> Who says that exactly one instruction must be emitted with the 
> optimizer
> off?  It seems to me that it would suffice to have the builtin function
> emit the one instruction in the case where the mask arguments, after 
> any
> optimization, are constant, and otherwise emit whatever code is needed 
> to
> compute the correct result (or simply emit a call to a library 
> function).

This violates the users expectations.

The _point_ of having builtins for single machine instructions is so 
that the generated code will use them (or something better).  Tweaking 
a builtin to generate an external lib call or 5 instructions instead of 
using that one machine instruction isn't, uhm, winning.

The one case were it would be winning, is if you wanted to use x86 
builtins on the ppc and the compiler did its best to make it just work.

Re: Help restricting args of an intrinsic function

[Joe Buck]

On Fri, Jan 30, 2004 at 07:59:34PM -0800, Mike Stump wrote:
> On Friday, January 30, 2004, at 05:38  PM, Diego Novillo wrote:
> > Yes, that's fine.  Here's what tree-ssa emits after the tree
> > optimization passes for the test cases you mentioned.
> 
> So, does your scheme work when the optimizer is off (-O0)?
> 
> If not, why would that be a solution?

Who says that exactly one instruction must be emitted with the optimizer
off?  It seems to me that it would suffice to have the builtin function
emit the one instruction in the case where the mask arguments, after any
optimization, are constant, and otherwise emit whatever code is needed to
compute the correct result (or simply emit a call to a library function).

Re: Help restricting args of an intrinsic function

[Mike Stump]

On Saturday, January 31, 2004, at 07:25 AM, Diego Novillo wrote:
> Syd seems to be looking for anything that the compiler can prove is a
> constant.

Ok, I'll buy that, but I don't think we want anything that can ever be 
turned off via an -O style option, or anything that is (or can be) 
machine dependent.

> Powerful != expensive.  Why are you considering such a simple data flow
> problem a non-starter?

We don't want to offer something that only compiles code on some 
machine or only compiles code with certain optimization settings.

The pointer case may be just beyond what we want to work.

Re: Help restricting args of an intrinsic function

[Diego Novillo]

On Sat, 2004-01-31 at 02:02, Mike Stump wrote:

> > Syd's problem can only be addressed if you have some
> > minimal data flow information available.
> 
> No.  Enumeration constants don't require data flow.  Intergral constant 
> expressions don't require data flow.
>
Syd seems to be looking for anything that the compiler can prove is a
constant.  Realizing that a pointer dereference is a compile time
constant *does* need dataflow info, however trivial.

>   I don't think Syd needs anything 
> as powerful as dataflow, just as powerful as fold.
>
Powerful != expensive.  Why are you considering such a simple data flow
problem a non-starter?

>   The problem is 
> these are frontend concepts and they may need to be handled by frontend 
> code.
>
No, they are not.  Syd's test case with pointer dereferences is not
something you can solve with an FE hook.


Diego.

Re: Help restricting args of an intrinsic function

[Joseph S. Myers]

On Fri, 30 Jan 2004, Syd Polk wrote:

> The problem is this:
> 
>    const int shift = 3;
>    r2 = __rlwimi (r, arg, shift, 5, 8);

So what *is* the specification (language-standard-level) of the valid
arguments?  shift here isn't an integer constant expression for C, only
for C++, so presumably you aren't wanting to restrict things to integer
constant expressions.  But "anything the compiler can show is constant"
(do you then allow a variable argument to a built-in function as long as
in every call to that function the argument is constant?) isn't a good
specification; with that as a specification, user code could break between
minor releases if a problematic optimisation that code depended on in this
way is disabled.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: Help restricting args of an intrinsic function

[Mike Stump]

On Friday, January 30, 2004, at 08:29  PM, Diego Novillo wrote:
>> So, does your scheme work when the optimizer is off (-O0)?
>>
> Of course not.

Then that's a problem, because the code should work regardless of the 
optimization setting.

> Syd's problem can only be addressed if you have some
> minimal data flow information available.

No.  Enumeration constants don't require data flow.  Intergral constant 
expressions don't require data flow.  I don't think Syd needs anything 
as powerful as dataflow, just as powerful as fold.  The problem is 
these are frontend concepts and they may need to be handled by frontend 
code.  Machine specific builtins don't have easy access to the frontend 
and it seems that to solve this problem, we'd probably need access to 
the frontend, that, or those constructs have to be language independent 
enough to be handled by language independent code, or they need to be 
simplified by the fronend before that.

Now, I've not checked to see what all isn't handled, but it might be 
the case that something as simple as t = fold (t); will do everything 
Syd needs....  but, in general, I suspect we might need a frontend 
hook...

Re: Help restricting args of an intrinsic function

[Diego Novillo]

On Fri, 2004-01-30 at 22:59, Mike Stump wrote:
> On Friday, January 30, 2004, at 05:38  PM, Diego Novillo wrote:
> > Yes, that's fine.  Here's what tree-ssa emits after the tree
> > optimization passes for the test cases you mentioned.
> 
> So, does your scheme work when the optimizer is off (-O0)?
> 
Of course not.  Syd's problem can only be addressed if you have some
minimal data flow information available.  If the other compilers claim
that they can get the convoluted cases with the optimizers turned off,
they are lying.

But you bring up a good point.  One of the ideas that are floating about
is to enable a minimal amount of optimization even at -O0.  Enabling
CFG, SSA and, say, DCE and the dominator optimizers would probably be a
reasonable idea.

You don't even need to do this analysis on trees.  If the tree
optimizers emit the call with the constants propagated, you just have to
match it in your RTL patterns.


Diego.

Re: Help restricting args of an intrinsic function

[Mike Stump]

On Friday, January 30, 2004, at 05:38  PM, Diego Novillo wrote:
> Yes, that's fine.  Here's what tree-ssa emits after the tree
> optimization passes for the test cases you mentioned.

So, does your scheme work when the optimizer is off (-O0)?

If not, why would that be a solution?

Re: Help restricting args of an intrinsic function

[Syd Polk]

On Jan 30, 2004, at 5:38 PM, Ian Lance Taylor wrote:

> Syd Polk <spolk@apple.com> writes:
>
>> However, for my problem-child argument, it has the following rtl:
>>
>> (gdb) p op
>> $2 = 0x77ed2c
>> (gdb) pr
>> (mem/u/f:SI (plus:SI (reg/f:SI 114 virtual-stack-vars)
>>          (const_int 24 [0x18])) [0 shift+0 S4 A32])
>> (gdb)
>>
>> How do I collapse it down to a const_int?
>
> You use a constraint of 'n'.
>
> Of course, you might get the fatal insn not recognized error, which is
> pretty non-ideal as error messages go.  Hmmm.

So, I get this error now as I mentioned before. Do I have to write some 
alternative patterns which convert the above kind of rtl to const_int 
patterns?

Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: Help restricting args of an intrinsic function

[Syd Polk]

On Jan 30, 2004, at 5:38 PM, Ian Lance Taylor wrote:

> Syd Polk <spolk@apple.com> writes:
>
>> However, for my problem-child argument, it has the following rtl:
>>
>> (gdb) p op
>> $2 = 0x77ed2c
>> (gdb) pr
>> (mem/u/f:SI (plus:SI (reg/f:SI 114 virtual-stack-vars)
>>          (const_int 24 [0x18])) [0 shift+0 S4 A32])
>> (gdb)
>>
>> How do I collapse it down to a const_int?
>
> You use a constraint of 'n'.
>
> Of course, you might get the fatal insn not recognized error, which is
> pretty non-ideal as error messages go.  Hmmm.

Of course, now I am getting this for the correct test case that I am 
working on. Sigh. Maybe I will have better luck next week.

Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: Help restricting args of an intrinsic function

[David Edelsohn]

>>>>> Syd Polk writes:

>> The PowerPC port already provides special 'h' and 'H' constraints
>> for the 32-bit version and 64-bit instructions.

	Duh!  Sorry, I was thinking output template.  Yes, "n" is the best
constaint available.

David

Re: Help restricting args of an intrinsic function

[Syd Polk]

On Jan 30, 2004, at 5:42 PM, David Edelsohn wrote:

>>>>>> Ian Lance Taylor writes:
>
>>> How do I collapse it down to a const_int?
>
> Ian> You use a constraint of 'n'.
>
> 	The PowerPC port already provides special 'h' and 'H' constraints
> for the 32-bit version and 64-bit instructions.
>

According to the internals manual:

n
An immediate integer operand with a known numeric value is allowed. 
Many systems cannot support assembly-time constants for operands less 
than a word wide. Constraints for these operands should use n rather 
than i.


h
MQ, CTR, or LINK register

I am a complete beginner to gcc, so forgive my naive questions. But 
what is the difference between these two? h looks like it is a 32 bit 
value. n looks like a general assembly-constant less than one word 
wide. Since the assembly constants I need are 5 bits wide, it looks 
like n is the correct one to use.

Why would I use h?



Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: Help restricting args of an intrinsic function

[David Edelsohn]

>>>>> Ian Lance Taylor writes:

>> How do I collapse it down to a const_int?

Ian> You use a constraint of 'n'.

	The PowerPC port already provides special 'h' and 'H' constraints
for the 32-bit version and 64-bit instructions.

David

Re: Help restricting args of an intrinsic function

[Diego Novillo]

On Fri, 2004-01-30 at 19:58, Syd Polk wrote:

> Not only that, but compile-time constants in a certain range.
> 
Yes, that's fine.  Here's what tree-ssa emits after the tree
optimization passes for the test cases you mentioned.  These aren't even
very hard, actually.

But if the tree optimizers can't tell whether an argument to __rlwimi is
constant, then there's a good chance that the user is doing something
really convoluted, which should at least warrant a warning.


--- foo.c -------------------------------------------------------------
f1 (int r, int arg)
{
  int r2;
  const int shift = 3;
  r2 = __rlwimi (r, arg, shift, 5, 8);
  return r2;
}

f2 (int r, int arg)
{
  int r2;
  enum tests { t1, t2, t3, t4, t5 };
  r2 = __rlwimi(r, arg, t3, 5, 8);
  return r2;
}
  
f3 (int r, int arg)
{
  int r2;
  const int foo = 5;
  const int *shiftPtr = &foo;
  r2 = __rlwimi (r, arg, *shiftPtr, 5, 8);
  return r2;
}
---------------------------------------------------------------------------



--- foo.c.t35.optimized ---------------------------------------------------
f1 (r, arg)
{
  return __rlwimi (r, arg, 3, 5, 8);
}


f2 (r, arg)
{
  tests t5 = 4;
  tests t4 = 3;
  tests t3 = 2;
  tests t2 = 1;
  tests t1 = 0;
  return __rlwimi (r, arg, 2, 5, 8);
}


f3 (r, arg)
{
  int T.3;
  T.3 = __rlwimi (r, arg, 5, 5, 8);
  return T.3;
}
---------------------------------------------------------------------------



Diego.

Re: Help restricting args of an intrinsic function

[Ian Lance Taylor]

Syd Polk <spolk@apple.com> writes:

> However, for my problem-child argument, it has the following rtl:
> 
> (gdb) p op
> $2 = 0x77ed2c
> (gdb) pr
> (mem/u/f:SI (plus:SI (reg/f:SI 114 virtual-stack-vars)
>          (const_int 24 [0x18])) [0 shift+0 S4 A32])
> (gdb)
> 
> How do I collapse it down to a const_int?

You use a constraint of 'n'.

Of course, you might get the fatal insn not recognized error, which is
pretty non-ideal as error messages go.  Hmmm.

Ian

Re: Help restricting args of an intrinsic function

[Syd Polk]

On Jan 30, 2004, at 4:55 PM, Ziemowit Laski wrote:

> Syd,
>
> Where are you checking value validity?  The AltiVec code does this in 
> the expand_builtin_... routines, since there are restrictions on some 
> AltiVec operands also.
> Or do you not have builtin expansion routines for the intrinsics at 
> all?

I have a custom expand_builtin routine based on the altivec routines.

Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: Help restricting args of an intrinsic function

[Syd Polk]

On Jan 30, 2004, at 4:53 PM, Ian Lance Taylor wrote:

> Syd Polk <spolk@apple.com> writes:
>
>> The problem is this:
>>
>>    const int shift = 3;
>>    r2 = __rlwimi (r, arg, shift, 5, 8);
>>
>> When I get the tree for the third arg, it is of type NOP_EXPR. I tried
>> just calling default_conversion() from c-typeck.c as an experiment,
>> knowing that it is C-specific. However, it still came out a NOP_EXPR.
>
> Why must you check this at the tree level?  Presumably you will
> eventually generate some insn.  The insn is presumably going to
> require a const int, since that is what the instruction requires.  Can
> you just have the insn verify that the values are in range, and give
> an error if not?
>

I have a constraint function that tries to do this:

/* Return 1 if C is a constant than can be encoded as a shift operator
   in a rlwimi or rlwinm instruction. */

int
shift_operand (rtx op, enum machine_mode mode ATTRIBUTE_UNUSED)
{
   HOST_WIDE_INT c;

   if (GET_CODE (op) != CONST_INT)
     return 0;

   c = INTVAL (op);
   return ((c >= 0) && (c < 32));
}

gdb shows me that the op has the following rtl for a constant int:

(gdb) p op
$1 = 0x40f0f33c
(gdb) pr
(const_int 5 [0x5])
(gdb)

which is great.

However, for my problem-child argument, it has the following rtl:

(gdb) p op
$2 = 0x77ed2c
(gdb) pr
(mem/u/f:SI (plus:SI (reg/f:SI 114 virtual-stack-vars)
         (const_int 24 [0x18])) [0 shift+0 S4 A32])
(gdb)

How do I collapse it down to a const_int?

> I mean, sure, it would be better to handle it at the tree
> level--you'll probably give a better error message.  But you can pass
> some of the job onto the final pass, can't you?
>

I would love to be able to do this.


Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: Help restricting args of an intrinsic function

[Syd Polk]

On Jan 30, 2004, at 4:54 PM, Diego Novillo wrote:

> On Fri, 2004-01-30 at 19:46, Syd Polk wrote:
>
>> How can I safely:
>> 	- Determine if a value is really a compile-time constant?
>> 	- Get the value of that constant?
>>
> If you could wait a little while until tree-ssa is merged in mainline,
> this would be relatively simple to implement inside the tree 
> optimizers.
>
> So, if the compiler cannot assert that the arguments are compile-time
> constants, you want to emit an error?

Not only that, but compile-time constants in a certain range.

__builtin_prefetch does something similar, but only supports actual 
integers in the source code; it has the same characteristics as my 
original implementation.

>
>
> Diego.
>
>
Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: Help restricting args of an intrinsic function

[Ziemowit Laski]

Syd,

Where are you checking value validity?  The AltiVec code does this in 
the expand_builtin_... routines, since there are restrictions on some 
AltiVec operands also.
Or do you not have builtin expansion routines for the intrinsics at all?

--Zem

On 30 Jan, 2004, at 16.46, Syd Polk wrote:

> I am trying to implement a few PowerPC intrinsics that are supported 
> by another PowerPC compiler. It is going pretty well in general 
> (thanks to help by Mike Stump), but now, I have hit a road block.
>
> The intrinsic I am trying to implement is rlwimi. The syntax is:
>
> 	__rwlimi (rA,rS, SH, MB, ME);
>
> rA is the output register.
> rS is the input.
> SH is the shift value; MB and ME are mask begin and mask end values.
>
> The problem is that the only valid values SH, MB and ME are constant 
> integers from 1 to 31 inclusively. I have an instruction pattern which 
> accepts valid calls like:
>
>   r2 = __rlwimi (r, arg, 3, 5, 8);
>
> This is cool. The next step was getting:
>
>   r2 = __rlwimi (r, arg, 789, 5, 8);
>
> to correctly flag that 789 was not a valid value. I did that by 
> calling TREE_CODE on the argument, checking to see if it is 
> INTEGER_CST, and then using compare_tree_int to see the constant 
> value. This is all cool.
>
> The problem is this:
>
>   const int shift = 3;
>   r2 = __rlwimi (r, arg, shift, 5, 8);
>
> When I get the tree for the third arg, it is of type NOP_EXPR. I tried 
> just calling default_conversion() from c-typeck.c as an experiment, 
> knowing that it is C-specific. However, it still came out a NOP_EXPR.
>
> Our competition handles this case just fine.
>
> This is just one example; there are others even worse:
>
>   enum tests {
> 	t1, t2, t3, t4, t5
>   };
>
>   r2 = __rlwimi(r, arg, t3, 5, 8);
>
> or
>
>   const int foo = 5;
>   const int *shiftPtr = &foo;
>   r2 = __rlwimi (r, arg, *shiftPtr, 5, 8);
>
> etc.
>
> (not to mention Ada or Fortran constructs)
>
> How can I safely:
> 	- Determine if a value is really a compile-time constant?
> 	- Get the value of that constant?
>
>
> Or, alternatively, is there a hook in the front-end parser that I can 
> tie into to flag the error at parse time?
>
> Syd Polk
> Apple Computer
> Technology EPM, Mac OS X Development Tools
> +1 408 974-0577
>
>
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: Help restricting args of an intrinsic function

[Diego Novillo]

On Fri, 2004-01-30 at 19:46, Syd Polk wrote:

> How can I safely:
> 	- Determine if a value is really a compile-time constant?
> 	- Get the value of that constant?
> 
If you could wait a little while until tree-ssa is merged in mainline,
this would be relatively simple to implement inside the tree optimizers.

So, if the compiler cannot assert that the arguments are compile-time
constants, you want to emit an error?


Diego.

Re: Help restricting args of an intrinsic function

[Ian Lance Taylor]

Syd Polk <spolk@apple.com> writes:

> The problem is this:
> 
>    const int shift = 3;
>    r2 = __rlwimi (r, arg, shift, 5, 8);
> 
> When I get the tree for the third arg, it is of type NOP_EXPR. I tried
> just calling default_conversion() from c-typeck.c as an experiment,
> knowing that it is C-specific. However, it still came out a NOP_EXPR.

Why must you check this at the tree level?  Presumably you will
eventually generate some insn.  The insn is presumably going to
require a const int, since that is what the instruction requires.  Can
you just have the insn verify that the values are in range, and give
an error if not?

I mean, sure, it would be better to handle it at the tree
level--you'll probably give a better error message.  But you can pass
some of the job onto the final pass, can't you?

Ian

Help restricting args of an intrinsic function

[Syd Polk]

I am trying to implement a few PowerPC intrinsics that are supported by 
another PowerPC compiler. It is going pretty well in general (thanks to 
help by Mike Stump), but now, I have hit a road block.

The intrinsic I am trying to implement is rlwimi. The syntax is:

	__rwlimi (rA,rS, SH, MB, ME);

rA is the output register.
rS is the input.
SH is the shift value; MB and ME are mask begin and mask end values.

The problem is that the only valid values SH, MB and ME are constant 
integers from 1 to 31 inclusively. I have an instruction pattern which 
accepts valid calls like:

   r2 = __rlwimi (r, arg, 3, 5, 8);

This is cool. The next step was getting:

   r2 = __rlwimi (r, arg, 789, 5, 8);

to correctly flag that 789 was not a valid value. I did that by calling 
TREE_CODE on the argument, checking to see if it is INTEGER_CST, and 
then using compare_tree_int to see the constant value. This is all 
cool.

The problem is this:

   const int shift = 3;
   r2 = __rlwimi (r, arg, shift, 5, 8);

When I get the tree for the third arg, it is of type NOP_EXPR. I tried 
just calling default_conversion() from c-typeck.c as an experiment, 
knowing that it is C-specific. However, it still came out a NOP_EXPR.

Our competition handles this case just fine.

This is just one example; there are others even worse:

   enum tests {
	t1, t2, t3, t4, t5
   };

   r2 = __rlwimi(r, arg, t3, 5, 8);

or

   const int foo = 5;
   const int *shiftPtr = &foo;
   r2 = __rlwimi (r, arg, *shiftPtr, 5, 8);

etc.

(not to mention Ada or Fortran constructs)

How can I safely:
	- Determine if a value is really a compile-time constant?
	- Get the value of that constant?


Or, alternatively, is there a hook in the front-end parser that I can 
tie into to flag the error at parse time?

Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577