[llvm-bugs] [Bug 48843] New: [AMDGPU][MC] Inconsistent behavior of "no*" modifiers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48843

            Bug ID: 48843
           Summary: [AMDGPU][MC] Inconsistent behavior of "no*" modifiers
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: AMDGPU
          Assignee: unassignedbugs at nondot.org
          Reporter: dpreobrazhensky at luxoft.com
                CC: llvm-bugs at lists.llvm.org

These modifiers are supported for the sake of compatibility with sp3. However
use of "no*" modifiers in llvm results in invalid code or counterintuitive
behavior.

Examples:

1. GFX8 buffer_store_lds_dword requires "lds" modifier:

    buffer_store_lds_dword s[4:7], s0 offset:4095 lds  // ok
    buffer_store_lds_dword s[4:7], s0 offset:4095      // error

However "nolds" is also accepted and results in the same code as "lds" variant.

    buffer_store_lds_dword s[4:7], s0 offset:4095 nolds  // ok?

There is a similar issue with buffer_load_* opcodes which support "lds" as an
optional modifier. These instruction accept "nolds" but handle it as if it were
"lds".

2. exp "done" modifier is optional:

    exp mrt0 v0, v0, v0, v0 done  // ok
    exp mrt0 v0, v0, v0, v0       // ok

However "nodone" is not supported.

3. ds_gws_* opcodes accept both "gds" and "nogds" but produce the same code.
Actually these opcodes have no lds variants so "nogds" should be illegal.

4. Most modifiers which affect operand size ("offen", "idxen", "glc", etc) can
be omitted, but "no*" variants trigger an error.

    buffer_load_format_x v5, off, s[8:11], s3          // ok
    buffer_load_format_x v5, off, s[8:11], s3 noidxen  // error

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210122/cc81d79e/attachment-0001.html>