The Hexagon tests were meant to check operations on vector predicate registers, so for them to work the inputs need to be vectors of i1 with the lengths that correspond to the lengths of vectors of 8+ bit integers. The only way to generate such values is do either a compare or a truncate. Since compare instructions can be fused with logical operations, this leaves truncate as the only option. With the changes from this patch, truncate is also eliminated, so it appears that these instructions cannot be emitted anymore (from a non-intrinsic code). With this in mind, I am ok with these changes.

I've run some tests and the results are not great for us. On some tests we got up to 5.5% improvements, but there are a lot of severe degradations (15+% worse). If this patch goes in, we'd like to be able to opt out.

This sounds good to me. I hope a better solution is developed later, but at least we get rid of the warning.

In D54962#1311537, @uweigand wrote:

Could we not simply add a way for the target to tell TableGen to not define any implicit compositions?

In D50977#1310153, @uweigand wrote:

@kparzysz, does that make sense to you?

In D50977#1309705, @uweigand wrote:

I must have missed the earlier discussion, but I agree with @bjope 's comment earlier that subreg_h32(V0) -> F0S is actually wrong; there should not be any subreg_h32(V0) at all!

Fixed the definition of subreg_l32 in the testcase.

Examine subregister (and composition) actions on all registers when detecting ambiguities. This eliminates the warning from the SystemZ build, but keeps the warning in the subreg_ll32 from earlier comments.

In D50725#1303747, @chandlerc wrote:

We're all still waiting on a fix here....

If Krzysztof can't address this, maybe the code owner for SystemZ (CC-ed I
believe) can take a look?

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.