[llvm-dev] [GlobalISel] How to properly handle the carry bit of G_UADDO/G_USUBO

15 views
Skip to first unread message

Dominik Montada via llvm-dev

unread,
Feb 14, 2020, 8:50:12 AM2/14/20
to llvm...@lists.llvm.org
Hi there,

we are working on a backend in GlobalISel and have a question regarding
the carry-in of the G_UADDO/G_USUBO instructions.

Taking inspiration from the AMDGPU and X86 backend we introduced a
pseudo register and non-allocatable register class which models our
carry bit and use a COPY instruction to/from this pseudo register. For
anything other than -O0 this already works fine, as the COPYs get
eliminated.

However on -O0 the COPY is not eliminated and we run into an assertion
in our copyPhysReg implementation, because we cannot COPY to this pseudo
register.

Again looking at AMDGPU and X86 I found two possible solutions to this
problem: AMDGPU seems to just emit an instruction which produces
conditionally a carry bit. Since it's just -O0 anyway we don't care
about these redundant instructions I guess.

X86 on the other hand seems to be using a machine pass which eliminates
COPYs to such a pseudo register.

What would be the proper way to handle this?

Also as a follow-up question: I noticed that I can mark the def of the
COPY to the pseudo register as DEAD and it will get eliminated. However
I am wondering if that is safe to do, even if its just a "pseudo copy"
anyway. Can somebody give some feedback here?

Cheers

Dominik

--
----------------------------------------------------------------------
Dominik Montada Email: dominik...@hightec-rt.com
HighTec EDV-Systeme GmbH Phone: +49 681 92613 19
Europaallee 19 Fax: +49-681-92613-26
D-66113 Saarbrücken WWW: http://www.hightec-rt.com

Managing Director: Vera Strothmann
Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient please notify the sender immediately
and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
---

Reply all
Reply to author
Forward
0 new messages