[all-commits] [llvm/llvm-project] 4d280d: Add testcases exposing PR44135

mikaelholmen via All-commits all-commits at lists.llvm.org
Tue Dec 10 02:25:05 PST 2019


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 4d280d3ac06aae0453859c83e025de8610596495
      https://github.com/llvm/llvm-project/commit/4d280d3ac06aae0453859c83e025de8610596495
  Author: Mikael Holmen <mikael.holmen at ericsson.com>
  Date:   2019-12-10 (Tue, 10 Dec 2019)

  Changed paths:
    A llvm/test/CodeGen/ARM/legalize-bitcast.ll

  Log Message:
  -----------
  Add testcases exposing PR44135


  Commit: 4763267eeee7ad0013d107b895dec1900b4f315f
      https://github.com/llvm/llvm-project/commit/4763267eeee7ad0013d107b895dec1900b4f315f
  Author: Mikael Holmen <mikael.holmen at ericsson.com>
  Date:   2019-12-10 (Tue, 10 Dec 2019)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
    M llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
    M llvm/test/CodeGen/ARM/legalize-bitcast.ll

  Log Message:
  -----------
  [LegalizeTypes] Bugfixes for big-endian targets when handling BITCASTs

Summary:
This fixes PR44135.

The special case when we promote a bitcast from a vector to an int
needs special handling when we are on a big-endian target.

Prior to this fix, for the added vec_to_int we see the following in the
SelectionDAG printouts

Type-legalized selection DAG: %bb.1 'foo:bb.1'
SelectionDAG has 9 nodes:
  t0: ch = EntryToken
        t2: v8i16,ch = CopyFromReg t0, Register:v8i16 %0
      t17: v4i32 = bitcast t2
    t23: i32 = extract_vector_elt t17, Constant:i32<3>
  t8: ch,glue = CopyToReg t0, Register:i32 $r0, t23
  t9: ch = ARMISD::RET_FLAG t8, Register:i32 $r0, t8:1

and I think here the extract_vector_elt is wrong and extracts the value
from the wrong index.

The program program should return the 32 bits made up of the elements at
index 4 and 5 in the vec6 array, but with

    t23: i32 = extract_vector_elt t17, Constant:i32<3>

as far as I can tell, we will extract values that originally didn't even
exist in the vec6 vectore.

If we would instead extract the element at index 2 we would get the wanted
values.

With this fix we insert a right shift after the bitcast in
DAGTypeLegalizer::PromoteIntRes_BITCAST which then gives us

Type-legalized selection DAG: %bb.1 'vec_to_int:bb.1'
SelectionDAG has 9 nodes:
  t0: ch = EntryToken
        t2: v8i16,ch = CopyFromReg t0, Register:v8i16 %0
      t23: v4i32 = bitcast t2
    t27: i32 = extract_vector_elt t23, Constant:i32<2>
  t8: ch,glue = CopyToReg t0, Register:i32 $r0, t27
  t9: ch = ARMISD::RET_FLAG t8, Register:i32 $r0, t8:1

So now we get

    t27: i32 = extract_vector_elt t23, Constant:i32<2>

which is what we want.

Similarly, the new int_to_vec testcase exposes a bug where we cast the other
direction. Then we instead need to add a left shift before the bitcast on
big-endian targets for the bits in the input integer to end up at the exptected
place in the vector.

Reviewers: bogner, spatel, craig.topper, t.p.northover, dmgreen, efriedma, SjoerdMeijer, samparker

Reviewed By: efriedma

Subscribers: eli.friedman, bjope, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70942


Compare: https://github.com/llvm/llvm-project/compare/dac5ddb48236...4763267eeee7


More information about the All-commits mailing list