[Diffusion] rL232374: [hexagon] Distinguish the 'o', 'v', and 'm' inline assembly memory constraints.

Krzysztof Parzyszek kparzysz at codeaurora.org
Mon Mar 16 10:06:50 PDT 2015

Hi Daniel,
The ConstraintCode that causes the failure is "i". The new Hexagon's 
implementation delegates constraint codes other than "m", "o" and "v" to 
the generic TLI's implementation, which aborts if the code is not "m".

In the selection DAG builder, the memory constraint is checked if the 
type is not "register" or "register class":

     case InlineAsm::isOutput: {
       if (OpInfo.ConstraintType != TargetLowering::C_RegisterClass &&
           OpInfo.ConstraintType != TargetLowering::C_Register) {
         // Memory output, or 'other' output (e.g. 'X' constraint).
         assert(OpInfo.isIndirect && "Memory output must be indirect 

         unsigned ConstraintID =
         assert(ConstraintID != InlineAsm::Constraint_Unknown &&
                "Failed to convert memory constraint code to constraint 

In case of "i", it will be "C_Other".


On 3/16/2015 11:11 AM, Daniel Sanders wrote:
> Hi,
> This commit caused failures on the Hexagon builders (e.g. http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/16716) but the tests work perfectly for me. Could someone take a look and let me know which value of ConstraintCode caused getInlineAsmMemConstraint() to return InlineAsm::Constraint_Unknown?
>    dsanders (Author)
> http://reviews.llvm.org/rL232374
>    http://reviews.llvm.org/settings/panel/emailpreferences/

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

More information about the llvm-commits mailing list