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

[Krzysztof Parzyszek]

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 
operand");

         unsigned ConstraintID =
             TLI.getInlineAsmMemConstraint(OpInfo.ConstraintCode);
         assert(ConstraintID != InlineAsm::Constraint_Unknown &&
                "Failed to convert memory constraint code to constraint 
id.");

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


-Krzysztof

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?
>
>
> USERS
>    dsanders (Author)
>
> http://reviews.llvm.org/rL232374
>
> EMAIL PREFERENCES
>    http://reviews.llvm.org/settings/panel/emailpreferences/
>
>


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