Re: [Open64-devel] Ignoring type argument for inline asm - need help debugging

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Rodrigo,

You are right that the input to CG already contains a U4INTCONST 1, so CG has no way of knowing it had a type cast. So to fix this the PathScale front-end generates:

    I4I1LDID 0 <2,2,s> T<2,.predef_I1,1>
   I4NEG
  I4CVTL 8
 U1STID 0 <2,4,asm.input_temp_0> T<6,.predef_U1,1>
 ...
 ...
   U4U1LDID 0 <2,4,asm.input_temp_0> T<6,.predef_U1,1>
  ASM_INPUT opnd:1 <2,5,c> # "c"

-Gautam

--- On Fri, 3/27/09, Rodrigo Dominguez <ro...@ho...> wrote:

From: Rodrigo Dominguez <ro...@ho...>
Subject: RE: [Open64-devel] Ignoring type argument for inline asm - need help debugging
To: "'Gautam Chakrabarti'" <gau...@ya...>, "'C.'" <cod...@os...>, ope...@li...
Date: Friday, March 27, 2009, 2:09 PM

Hi Gautam,

Thanks for your help. You were right. There is a “CVTL 8” applied on the 32-bit value. Although I haven’t found the problem yet, I debugged CG and found that the (uint8_t)(-s) expression is represented by a INTCONST = 1 node in the WHIRL . This doesn’t seem right, does it? (I may be wrong again!). It seems the constant was propagated to the __asm__ statement. Any help is appreciated!

Regards,

Rodrigo

From: Gautam Chakrabarti [mailto:gau...@ya...] 
Sent: Thursday, March 26, 2009 2:03 AM
To: Rodrigo Dominguez; C.; ope...@li...
Subject: Re: [Open64-devel] Ignoring type argument for inline asm - need help debugging

Hello,

I have not stepped through the compiler with this testcase, but I assume a "CVTL 8" is applied on the 32-bit value. In that case it is not wrong. The problem can be fixed in a slightly different way in Wgen_Expand_Asm_Operands.

A more general issue here is since PathScale's internal sources already contain this fix, how can it be propagated upstream into Open64 code base. If this bug is fixed elsewhere, probably in a slightly different way, it would make future source code merging even more cumbersome. I will leave this to other Open64 admins on this list to decide if this can be resolved.

Gautam

From: Rodrigo Dominguez <ro...@ho...>
To: Gautam Chakrabarti <gau...@ya...>; C. <cod...@os...>; ope...@li...
Sent: Wednesday, March 25, 2009 1:48:38 PM
Subject: RE: [Open64-devel] Ignoring type argument for inline asm - need help debugging

Hello,

I did some debugging of wgen_stmt.cxx using the unit test program below and
I think I am getting closer. This is what I think is going on. Let me know
if I am missing something:

The problem can be seen by looking at input_rvalue->common.rtype after line
1490 in the function ‘Wgen_Expand_Asm_Operands’. Here rtype = MTYPE_U4
(32-bit unsigned integer) even though the cast is uint8_t (8-bit unsigned
integer). This is wrong.

Following the function call on line 1490, in wgen_expr.cxx:WGEN_Expand_Expr
line 4837:

      if (MTYPE_size_min(mtyp) < MTYPE_size_min(WN_rtype(wn))) {
        if (MTYPE_size_min(mtyp) != 32)
          wn = WN_CreateCvtl(OPR_CVTL, Widen_Mtype(mtyp), MTYPE_V,
                    MTYPE_size_min(mtyp), wn);

Here mtyp = MTYPE_U1 (8-bit unsigned integer) as it should be given the
cast, and WN_rtype(wn) = MTYPE_I4 (32-bit integer) as it should be given the
C promotion rules applied on '-s'. Therefore, WGEN_Expand_Expr ends up
widening mtyp to MTYPE_U4.

The question is: why is WGEN_Expand_Expr widening mtyp to MTYPE_U4?

Thank you,

Rodrigo

From: Gautam Chakrabarti [mailto:gau...@ya...] 
Sent: Wednesday, March 25, 2009 3:10 AM
To: C.; ope...@li...
Subject: Re: [Open64-devel] Ignoring type argument for inline asm - need
help debugging

Hello Christopher,

The shipping version of the PathScale compiler also has this bug, although I
have already fixed this bug along with several other related ones in the
latest internal version. Many of these fixes are in
be/cg/x8664/cgtarget.cxx, where the original code misses many of the type
conversion hints to figure out the proper size of the register to use. But
the fix for this bug appears to be in wgen_stmt.cxx.

While I don't think the problem is in libspin, in order to read libspin
output, you can run 'make' in the usual ways for libspin, which will
generate gspin and gspin42 in addition to the libraries. To debug a -gnu42
front-end, pass the .spin file to gspin42, you will see a text version of
the IR in stdout.

Tips on debugging this: basically you need to see the WHIRL being input to
CG, and whether from that it is possible for CG to determine the size of the
register to use. If it is possible, then it's a CG bug. If it is not
possible, the problem is coming from a previous phase.

-O0 seems to be a workaround.

Gautam

________________________________________
From: C. <cod...@os...>
To: ope...@li...
Sent: Tuesday, March 24, 2009 1:41:12 AM
Subject: [Open64-devel] Ignoring type argument for inline asm - need help
debugging

I hit a bug I'd *really* like to get it fixed.

1.s: Assembler messages:
1.s:53: Error: suffix or operands invalid for `shr'

Rodrigo helped make a small test case. (thanks)
----
#include <stdint.h>

int main(void)
{
    uint32_t    a = 7;
    int8_t      s = -1;

    __asm__ ("shrl %1, %0\n\t"
            : "+r" (a)
            : "c" ((uint8_t)(-s))
              );

    return a;
}
------

I'm quickly stepping through the phases for opencc and here's what I 
think is going on.  Someone please correct me if I'm wrong.

    * opencc
          o gcc -o test-uint8_t.c test-uint8_t.i
          o cc142 test-uint8_t.c test-uint8_t.i -spinfile test-uint8_t.spin
          o wgen42 -fS,test-uint8_t.spin -fB,test-uint8_t.B
          o ipl -PHASE:p:i -fB,test-uint8_t.B -fo,test-uint8_t.o
            test-uint8_t.c
          o (some dummy gcc calls?)
          o ipa_link  test-uint8_t.o
                + ld-new
                + Creates a.out.ipakeep/1.s at this point?
                + be -PHASE:w:c -fB,1.I -s -fs,1.s 1.I (Should this be
                  one level higher.. not sure if it's part of the
                  a.out.ipakeep/makefile)
                + gcc -m32 1.s -c -o 1.o

The end problem is that s needs to be an 8 bit register and open64 is is 
ignoring the size of the parameter being passed to the inline asm.  I 
can give the compiler a hint by changing adding %b1 /* __asm__ ("shrl 
%b1, %0\n\t"  */ , but I end up hitting some code where this would be 
too tedious.

- shrl %ecx, %edx
+ shrl %cl, %edx

I'm trying to figure out exactly where the culprit is...

whirl2c -TARG:abi=n32 test-uint8_t.B
typedef signed char _INT8;
_INT8 anon2;
(That doesn't seem to be the problem)

So I did my best to pull out some data from the test-uint8_t.spin

With a hex editor this is the best I could get out of it, but probably 
not helpful
http://pastealacon.com/2333
(It expires soon, but can upload if someone wants to look.)

Questions:

  1. What tool to use to examine a *.spin file?
  2. Where to look to try to fix this?
  3. Tips on debugging this stuff?
  4. Any work-around that doesn't involve user code changes?

I know the CGO conference is keeping everyone busy, but if anyone does 
have a chance to look it's really appreciated.

./Christopher

----------------------------------------------------------------------------
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Open64-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/open64-devel