search for: simplifybinopwithsameopcodehands

...aced it by (trunc (or (aext x), (aext y))). Now the problem is that the DAG Combiner optimizes it back to an i1 OR operations that is not supported by the architecture. What is the best way to solve this problem? I take a look at the DAG Optimizer and for this OR operation it calls DAGCombiner::SimplifyBinOpWithSameOpcodeHands that folds (OP (aext x), (aext y)) -> (aext (OP x, y)). No check if the new operation is legal is performed. Kind regards Timo Stripf -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090823/272a6e3...

...(ISD::OR, MVT::i1, Promote); If you can get your target to work with a legal i1 type, it would be great. The Blackfin target could use that as well. > What is the best way to solve this problem? I take a look at the > DAG Optimizer and for this OR operation it calls > DAGCombiner::SimplifyBinOpWithSameOpcodeHands that folds (OP (aext > x), (aext y)) -> (aext (OP x, y)). No check if the new operation is > legal is performed. When LegalOperations is set, the DAG combiner must not create illegal operations. It is a bug if it does. I recently fixed this in the first if statement in SimplifyBin...

...esirableForOp() and > IsDesirableToPromoteOp() may help you here. X86 does something similar. I just tried these functions, and it seems like they are only modifying the behavior of type promotions for a small subset of operations (PromoteIntBinOp, PromoteIntShiftOp, PromoteExtend, PromoteLoad, SimplifyBinOpWithSameOpcodeHands, visitSRL, visitTRUNCATE that matter to the performance of i16 on X86.) I don't like the "desirable" in the name of these functions: in the case of Hexagon it is illegal to use an i8 predicate register for anything else than setcc, brcond, and the logical ops: so doing the conversion...

...nc i64 %shr to i32 IC: Visiting: %conv3 = trunc i64 %mul to i32 IC: Visiting: %xor = xor i32 %conv3, %conv2 IC: ADD: %xor6 = xor i64 %mul, %shr IC: Old = %xor = xor i32 %conv3, %conv2 New = <badref> = trunc i64 %xor6 to i32 * which seems to be performed by SDValue DAGCombiner::SimplifyBinOpWithSameOpcodeHands(SDNode *N) In my backend's architecture truncate is free, but zext is not (and i64 is not a desirable type for xor or any binary operation in general), so I would expect this optimization to be bypassed but because of the following statement : (N0.getOpcode() == ISD::TRUNCATE && (...

...m you if i get it running. I successfully compiled and simulated jpeg 2000 encoder/decoder before I ran into this problem. > When LegalOperations is set, the DAG combiner must not create illegal > operations. It is a bug if it does. I recently fixed this in the first > if statement in SimplifyBinOpWithSameOpcodeHands(). Perhaps you could > add a check to the second if statement and submit a patch? That sounds nice. I'll try out the svn code tomorrow. I think it'll take some days to converted the back-end to the new code base. -Timo -----Ursprüngliche Nachricht----- Von: Jakob Stoklund Olesen [m...

...IsDesirableToPromoteOp() may help you here. X86 does something similar. > > I just tried these functions, and it seems like they are only > modifying the behavior of type promotions for a small subset of > operations (PromoteIntBinOp, PromoteIntShiftOp, PromoteExtend, > PromoteLoad, SimplifyBinOpWithSameOpcodeHands, visitSRL, visitTRUNCATE > that matter to the performance of i16 on X86.) > > I don't like the "desirable" in the name of these functions: in the > case of Hexagon it is illegal to use an i8 predicate register for > anything else than setcc, brcond, and the logical ops:...

Hi Sebastian, On 22/05/2012 23:25, Sebastian Pop wrote: > Hi Eli, > > On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman<eli.friedman at gmail.com> wrote: >> On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum<tlinth at codeaurora.org> wrote: >>> Hey folks, >>> >>> We are having some difficulty with how we have been representing our >>>

Hi Eli, On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: >> Hey folks, >> >> We are having some difficulty with how we have been representing our >> predicate registers, and wanted some advice from the list.  First, we >> had been

...here. X86 does something > >> similar. > > > > I just tried these functions, and it seems like they are only > > modifying the behavior of type promotions for a small subset of > > operations (PromoteIntBinOp, PromoteIntShiftOp, PromoteExtend, > > PromoteLoad, SimplifyBinOpWithSameOpcodeHands, visitSRL, > > visitTRUNCATE that matter to the performance of i16 on X86.) > > > > I don't like the "desirable" in the name of these functions: in the > > case of Hexagon it is illegal to use an i8 predicate register for > > anything else than setcc, brc...