Thanks!

Thanks for the investigation. What concerns me a bit is that this isn't the only place where this pattern occurs, but hopefully it will be detected if it causes problems. It would be nice to have enough data to file a bug report against stdc++, but for now we can apply this workaround.

Hexagon packets (bundles) have 4 slots, numbered 0..3. Each one of the three instructions (2 x S2_extractu, and PS_call_nr) can only go in slots 2 or 3, so something went horribly wrong.

The encoding of an instruction includes encodings of its operands. How are you planning to implement separate encoder/decoder methods? Right now their names are all embedded into operand definitions.

Hexagon clang builder has been failing since around the time of this commit as well:
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/20617/steps/ninja%20check%201/logs/stdio

What thread was that discussion in? Accesses to device-mapped memory can trap, what is the reason for the compiler to assume that they can't?

Right at the beginning of CodeGenRegBank::computeComposites, I added

In D50977#1246893, @bjope wrote:

So it should not be possible to do subreg_h32(V0), right?

The warning seem to be plain wrong. The warning claims that

warning: SubRegIndex SystemZ::subreg_h64 and SystemZ::subreg_h32 compose ambiguously as SystemZ::subreg_hh32 or SystemZ::subreg_h32

This is based on V0: subreg_h64(V0) = F0D, subreg_h32(F0D) = F0S. So the composition (and subreg_hh32, user-defined as that composition) maps V0 to F0S. Now subreg_h32(V0) = F0S, so for V0 these two indeed agree. This is the cause for the warning.
However, for F0Q, subreg_h32(subreg_h64(F0Q)) = subreg_h32(F0D) = F0S, while subreg_h32(F0Q) = F2S. So, while these compositions agree on at least one register, they are not equal in general.

I've looked into this and there is no way to distinguish the case of hh (no warning) and ll (emit a warning). They are both equivalent: a user-defined composition vs. pre-existing subreg.

In general, looking at a single instruction is not sufficient to tell whether a given register becomes dead or not, so I wouldn't worry about the limitation you mentioned. Cases that we can reliably handle are (sub)ranges corresponding to the parts of the register that is given in the operand (i.e. the entire register if there is no subregister).

The conflict between user-defined and inferred compositions causes a warning in the SystemZ build:

warning: SubRegIndex SystemZ::subreg_h64 and SystemZ::subreg_h32 compose ambiguously as SystemZ::subreg_hh32 or SystemZ::subreg_h32

Ping.

Ping.

Ping.

It should be possible to move this loop out of the nest and only have it iterate over the preexisting patterns. Could you see if that generates different .inc files (it shouldn't)?

Ping.

Already implemented.

The fixes have been committed individually.

The practical application of this is to indicate aliasing with a given memory object, but without specifying exactly which part of the object is accessed (since it may be unknown). Dropping memory operands altogether will alias the operation with all other objects, so it will be correct, but overly conservative.

Yes, I do have one. I'll post it on Monday.

Thanks for finding all these things!

We should convert the copy to an IMPLICIT_DEF, but this patch is good as is.

Ping.

That warning can be eliminated by resolving such conflicts in favor of user-defined compositions.

The problem is in how tblgen calculates sub-registers. For a given register R, subreg indices of its sub-registers will be added to R, in other words a super-register "inherits" subreg indices from its subregisters. For example, V0 (from class VR128) has an explicit subreg index subreg_h64. It also has a sub-register F0D, which has a subreg index subreg_h32. As a result, V0 will have two subreg indices: subreg_h64 and subreg_h32. From the register structure (V0 vs F0D vs F0S) it is inferred that the composition V0.subreg_h64.subreg_h32 is same as V0.subreg_h32, a in general that the composition subreg_h64.subreg_h32 is equivalent to subreg_h32. At the same time, repeating this logic for a register F0Q from class FPR128 leads to adding subreg_h32 twice, which tblgen tries to resolve by referring to user-defined compositions. This is how subreg_hh32 shows up. However, now there is another result for composing subreg_h64.subreg_h32, hence the warning.

Looks good to me.

A bit of a background for clarity: <Something>ByHwMode represents <Something> parameterized by hardware mode. It's a map that to each hw mode assigns the corresponding value of <Something>. If a value for mode m is missing from the map, the default is used (this is a form of compression).

Will investigate.

This looks good. Do you have a testcase that demonstrates what this pass does?

Running tblgen with -debug shows

This situation is the same as the case of RAX vs EAX on X86. EAX is the lower half of RAX, but modifying EAX does not preserve the upper bits of RAX. On the other hand, modifying AX (lower half of EAX) does preserve the upper half of EAX. Originally, the former behavior was modeled for both cases, i.e. overwriting a lone subregister would be considered as overwriting the entire register. I added phony registers to X86 (e.g. HAX covering the upper half of EAX) to model the latter behavior for EAX, EBX, etc.

The option would be great. Then I could commit the fixes individually with the corresponding testcases.

I included the testcase changes into D50648, so this patch is no longer necessary.

This is just a demonstration of what I meant in the comments for llvm.org/PR38544: getting rid of explicit overlapping subregister indices solves the problem encountered in tc_subregliveness_noliveseg.ll.

Fixes for remaining testcases, except tc_subregliveness_noliveseg.ll. That one requires D50725.