Displaying 3 results from an estimated 3 matches for "custom_add_i32".
2011 Jan 04
4
[LLVMdev] Bug in MachineInstr::isIdenticalTo
...Notice how except for the sizes of the pointer, the sequence is the same. This translates into the following for my backend at the MI level.
BB#9: derived from LLVM BB %switch.case55
Live Ins: %R258 %R260 %R259
Predecessors according to CFG: BB#8
%R257<def> = CUSTOM_ADD_i32 %R260<kill>, %R258<kill>
%R258<def> = VEXTRACT_v4i32 %R259<kill>, 1
GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST1[%arrayidx]
RETURN
BB#10: derived from LLVM BB %switch.case61...
2011 Jan 04
0
[LLVMdev] Bug in MachineInstr::isIdenticalTo
...for the sizes of the pointer, the sequence is the same. This translates into the following for my backend at the MI level.
> BB#9: derived from LLVM BB %switch.case55
> Live Ins: %R258 %R260 %R259
> Predecessors according to CFG: BB#8
> %R257<def> = CUSTOM_ADD_i32 %R260<kill>, %R258<kill>
> %R258<def> = VEXTRACT_v4i32 %R259<kill>, 1
> GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST1[%arrayidx]
> RETURN
>
> BB#10: derived from...
2009 Jun 04
1
[LLVMdev] Subsuming a memory node of a TargetGlobalAddress with a TargetConstant node
...d does not support. The TargetGlobalAddress is assumed to
always be of ConstantInt or ConstantFP type, so this transformation is
valid. I am correctly able to modify the dag and remove all of the uses
of the node as specified in the attached before and after dot images.
The nodes in question is the CUSTOM_ADD_i32(0x002EDE80) ->
load(0x002EDAC8), but I am not able to figure out how to correctly
modify the chain and point the TokenFactor(0x002EDBD8) node to the
llvm.opencl.other.get.global.id(0x002ED3E0) node so that I can
completely remove the load, undef, and targetglobaladdress nodes.
If anyone can...