Sorry, accidently hit send hotkeys before finishing email.
I am still trying to figure out why my comparison instructions are being
modified and overall producing incorrect results.
The IR produces correct results, but my backend does not and the only
thing I can think of is that the IR is treating the Booleans as i1 and
therefore either and'ing or xor'ing the results of my comparison with
the value 1.
This is causing the IR after running opt to be correct, but when it hits
my backend, there are some changes that generate something weird.
int gID = width;
const int idx = gID % 64;
const int idy = gID / 64;
pv[gID] = 0;
if( idy > 63 && idx > 0 )
{
pv[gID]=1;
}
generates conditionals :
ult r1043.x, 63, r1026.x
ilt r1041.x, r1039.x, 1
and r1041.x, r1041.x, r1043.x
if_logicalz r1041.x
//write to pv
endif
which is C for
if ((63 < idy && idx < 1) == 0) {
}
I have no clue how the 1 gets put in there but being able to stop the
xor/and instructions from being inserted and modifying my comparison
instructions would help me pinpoint where the error is.
Micah
________________________________
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Chris Lattner
Sent: Tuesday, November 18, 2008 1:00 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] 32 bit boolean results
On Nov 18, 2008, at 11:24 AM, Villmow, Micah wrote:
Is there a way to tell LLVM to treat Boolean results as 32bit values
instead of 1 bit values?
LLVM IR doesn't have a concept of C level booleans. What problem are
you trying to solve?
-Chris
Thanks,
Micah Villmow
Systems Engineer
Advanced Technology & Performance
Advanced Micro Devices Inc.
4555 Great America Pkwy,
Santa Clara, CA. 95054
P: 408-572-6219
F: 408-572-6596
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20081118/2b984a91/attachment.html>
On Tue, Nov 18, 2008 at 1:56 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:> The IR produces correct results, but my backend does not and the only thing > I can think of is that the IR is treating the Booleans as i1 and therefore > either and'ing or xor'ing the results of my comparison with the value 1.CodeGen assumes that SETCC(true condition) & 1 == 1, and SETCC(false condition) & 1 == 0. For details, look in SelectionDAGNodes.h. If your comparisons are returning something unusual, you may have to custom-lower them.> I have no clue how the 1 gets put in there(!(idx > 0)) == (idx <= 0) == (idx < 1). Most likely the DAGCombiner is doing this. What should be happening is something like the following: Branch lowering transforms the code into something like the following to save a jump: if (!(idy > 63 && idx > 0)) goto afterif; <code in if> afterif: <code after if> Then, !(idy > 63 && idx > 0) gets combined to (idy < 64 || idx < 1). Then, your legalization transforms the branch condition into (!(idy < 64 || idx < 1) == 0). Then, combine reorganizes this back into (idy > 63 && idx > 0). It's hard to say where this is messing up. -Eli
You can tell LLVM that you have "sign extended" setCC results (all ones). Dan On Nov 18, 2008, at 5:33 PM, Eli Friedman wrote:> On Tue, Nov 18, 2008 at 1:56 PM, Villmow, Micah > <Micah.Villmow at amd.com> wrote: >> The IR produces correct results, but my backend does not and the >> only thing >> I can think of is that the IR is treating the Booleans as i1 and >> therefore >> either and'ing or xor'ing the results of my comparison with the >> value 1. > > CodeGen assumes that SETCC(true condition) & 1 == 1, and SETCC(false > condition) & 1 == 0. For details, look in SelectionDAGNodes.h. If > your comparisons are returning something unusual, you may have to > custom-lower them. > >> I have no clue how the 1 gets put in there > > (!(idx > 0)) == (idx <= 0) == (idx < 1). Most likely the DAGCombiner > is doing this. > > What should be happening is something like the following: > Branch lowering transforms the code into something like the following > to save a jump: > if (!(idy > 63 && idx > 0)) goto afterif; > <code in if> > afterif: > <code after if> > > Then, !(idy > 63 && idx > 0) gets combined to (idy < 64 || idx < 1). > > Then, your legalization transforms the branch condition into (!(idy < > 64 || idx < 1) == 0). > > Then, combine reorganizes this back into (idy > 63 && idx > 0). > > It's hard to say where this is messing up. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev