[llvm-commits] [PATCH] - Bug 8621 - inline asm - please review

[John Thompson]

Chris, you are too quick!

Thanks. (Or the response in the bug report.)
-John
On Wed, Nov 17, 2010 at 3:29 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> From my comment to the bug:
>
> It looks like a problem with the back end.
>
> I reduced the test case to:
>
> void func()
> {
>   unsigned int src = 0, dst = 0;
>   static const unsigned long flagmask = 1;
>   unsigned long flags = 1;
>   unsigned long newflags = ~(0UL);
>   asm (
>     "pushfq \n"
>     "andq %2, (%%rsp) \n"
>     "orq  %3, (%%rsp) \n"
>     "popfq \n"
>     "addb %4, %1 \n"
>     "pushfq \n"
>     "popq %0 \n"
>        :
>           "=&rm" (newflags) ,
>           "=&rm" (*(unsigned char *)&dst)
>        :
>           "i" (~flagmask) ,
>           "r" (flags & flagmask) ,
>           "r" (*(unsigned char *)&src) ,
>           "1" (*(unsigned char *)&dst)
>        : "cc");
> }
>
> The constraints involved in the problem are index 1 and 5, which we see do
> match types in the above code.
>
> This change seems to fix it:
>
> Index: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
> ===================================================================
> --- lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (revision 119175)
> +++ lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (working copy)
> @@ -5545,9 +5545,6 @@
>      // If this is an input or an indirect output, process the call
> argument.
>      // BasicBlocks are labels, currently appearing only in asm's.
>      if (OpInfo.CallOperandVal) {
> -      // Strip bitcasts, if any.  This mostly comes up for functions.
> -      OpInfo.CallOperandVal = OpInfo.CallOperandVal->stripPointerCasts();
> -
>        if (const BasicBlock *BB =
> dyn_cast<BasicBlock>(OpInfo.CallOperandVal)) {
>          OpInfo.CallOperand = DAG.getBasicBlock(FuncInfo.MBBMap[BB]);
>        } else {
>
> The removed code apparently was stripping the pointer cast.  I don't know
> the original reason for it.
>
> I ran the LLVM regression tests, test suite, and gcc tests, with no
> differences.  Does this seem like the correct fix?  If so, let me know and
> I'll check this in.  Or was there a reason for the cast stripping?
>
> It doesn't appear to be related to my inline asm work.
>
> -John
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101117/71fe4517/attachment.html>