From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28987 invoked by alias); 31 Jan 2004 00:55:23 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28962 invoked from network); 31 Jan 2004 00:55:22 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 31 Jan 2004 00:55:22 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.11) with ESMTP id i0V0tLBv013096 for ; Fri, 30 Jan 2004 16:55:21 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 30 Jan 2004 16:55:20 -0800 Received: from [17.201.24.57] (polskifiat.apple.com [17.201.24.57]) by relay2.apple.com (8.12.9/8.12.11) with ESMTP id i0V0t3t9025170; Sat, 31 Jan 2004 00:55:04 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D97AC2E-5388-11D8-BF29-000393673036@apple.com> Content-Transfer-Encoding: 7bit Cc: GCC List From: Ziemowit Laski Subject: Re: Help restricting args of an intrinsic function Date: Sat, 31 Jan 2004 00:58:00 -0000 To: Syd Polk X-SW-Source: 2004-01/txt/msg02298.txt.bz2 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