Displaying 7 results from an estimated 7 matches for "carry1".
Did you mean:
carry
2020 Mar 12
4
Correct modelling of instructions with types smaller than the register class
...mething to map to
> when you do register bank select.
> The register class could be "not allocatable” (see CCR in AArch64 for
> instance).
> Note, that if that class is unallocable, you’ll have to manage
> manually any overlapping that could arise.
> E.g.,
> s32 ..., s1 carry1 = G_UADDO
> s32 ..., s1 carry2 = G_UADDO
> s32 extended_carry1 = zext s1 carry1 <— carry1 will be destroyed by
> the second G_UADDO, you’ll have to fix the schedule or copy the value
> manually.
> s32 extended_carry2 = zext s1 carry2
> icmp s32 extended_carry1, extended_carry...
2013 Jun 28
3
[LLVMdev] Question regarding the x86 SBB instruction.
...y] = llvm.ssub.with.overflow.i32 %edx1, %eax2 (carry ==
0, but I want it to be 1)
So, the problem only occurs with the edge case of %eax == 0xffffffff
and carry == 1
Any ideas how I could make this work accurately in LLVM IR ?
I could put an if round it:
if ((%eax1 == 0xffffffff)) && (%carry1 == 1)) {
%carry2 = 1
} else {
%eax2 = ADD i32 %eax1, %carry
[%edx2,%carry3] = llvm.ssub.with.overflow.i32 %edx1, %eax2
}
%carry4 = phi (%carry2, %carry3) (true branch, else branch)
%edx3 = phi (%edx1, %edx2)
branch cond %carry4 jump_destination
Any better ideas?
James
2020 Mar 02
2
Correct modelling of instructions with types smaller than the register class
Hi Quentin,
thank you for the reply! This clears up a lot of the questions I was
having. It seems like we should definitely invest some time in rewriting
some of our legalization rules then! I also posted some questions
further down below. I would appreciate getting your opinion on them.
> Hi Dominik,
>
> I’ll do a brief reply here and if you want more information we can talk further
2013 Jun 28
0
[LLVMdev] Question regarding the x86 SBB instruction.
...%eax2 (carry ==
> 0, but I want it to be 1)
>
> So, the problem only occurs with the edge case of %eax == 0xffffffff
> and carry == 1
>
> Any ideas how I could make this work accurately in LLVM IR ?
> I could put an if round it:
> if ((%eax1 == 0xffffffff)) && (%carry1 == 1)) {
> %carry2 = 1
> } else {
> %eax2 = ADD i32 %eax1, %carry
> [%edx2,%carry3] = llvm.ssub.with.overflow.i32 %edx1, %eax2
> }
> %carry4 = phi (%carry2, %carry3) (true branch, else branch)
> %edx3 = phi (%edx1, %edx2)
> branch cond %carry4 jump_destination
>...
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
> Can you explain why you chose the approach of using a new pass?
> I pictured removing LegalizeDAG's type legalization code would
> mostly consist of finding all the places that use TLI.getTypeAction
> and just deleting code for handling its Expand and Promote. Are you
> anticipating something more
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 1:34 PM, Eli Friedman wrote:
> On Wed, May 20, 2009 at 1:19 PM, Eli Friedman
> <eli.friedman at gmail.com> wrote:
>
>> Per subject, this patch adding an additional pass to handle vector
>>
>> operations; the idea is that this allows removing the code from
>>
>> LegalizeDAG that handles illegal types, which should be a significant
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...Node->getOpcode() == ISD::ADD) {
- Lo = DAG.getNode(ISD::ADD, dl, NVT, LoOps, 2);
- Hi = DAG.getNode(ISD::ADD, dl, NVT, HiOps, 2);
- SDValue Cmp1 = DAG.getSetCC(dl, TLI.getSetCCResultType(NVT),
- Lo, LoOps[0], ISD::SETULT);
- SDValue Carry1 = DAG.getNode(ISD::SELECT, dl, NVT, Cmp1,
- DAG.getConstant(1, NVT),
- DAG.getConstant(0, NVT));
- SDValue Cmp2 = DAG.getSetCC(dl, TLI.getSetCCResultType(NVT),
- Lo, LoOps[1], ISD::SETU...