These opcodes have been deprecated about a year ago, but still in use in various backend.

In I would like to change the behavior of the backend to not enable the use of these opcodes by default. The opcode remains usable by any backend that wish to use them, but that should limit the situation where newer backend just use them as they are enabled by default.

This shouldn’t break any out of tree backend, however, it may cause misoptimisation if the backend dev do not activate these opcodes via setOperationAction and rely on them for some of their optimizations.

I would like to gather some feedback about moving forward with that as it can impact a wide range of users.

So, feedback ?

Thanks in advance for your answers,

Amaury Séchet

For targets where ADDCARRY and SUBCARRY are legal, would it make sense to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)?

Are there plans to deprecate UADDO/USUBO in favor of ADDCARRY/SUBCARRY?


SelectionDAG will never generate ADDC/ADDE on targets where they aren't legal. Targets which custom-lower ADDCARRY generally also custom-lower UADDO; not sure what sort of expansion you're thinking of.


If ADDC/ADDE cannot ever appear, then that's ok. The expansion of a long ADD will generate UADDO for the first addition. UADDO is unnecessary since ADDCARRY already includes UADDO's functionality, so if target sets UADDO to Expand, it could be replaced with ADDCARRY. Targets can handle both manually, but why should they have to?

I was actually working on using ADDCARRY on Hexagon and I find the UADDO generation a little annnoying.


If the expansion of UADDO would be useful, patch welcome, I guess. (It isn't useful on architectures like ARM; we have to special-case UADDO anyway to generate "adds" instead of "adcs".)



Thanks for heads up, this will impact the OR1K backend.

Is there any guidance for migrating to U*O/*CARRY?

If your target has a dedicated flags/carry register (x86/ARM/etc.), see for a description of how to add the necessary conversions to get efficient lowering. Otherwise, the correct lowering should be obvious; see .


These guidelines are good. The X86 backend does something very similar.

I meant this for llvm-dev...

Wouldn't that be the same as special-casing ADDCARRY with zero carry-in?