[llvm-dev] Combine redundant instructions

Yaoqing Gao via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 15 06:49:14 PDT 2016


Hello,

I am still in process to get an account to access https://llvm.org/bugs/.
So I would like to post it here for discussion first.

It looks there is a problem with "Combine redundant instructions".

Given the following simple example:

#include "stdio.h"
#include "stdint.h"
struct A {
  uint8_t pedding;
  uint64_t integer:48;
}__attribute__ ((__packed__));

__attribute__((noinline))
void foo(struct A * ptr) {
  ptr->integer = 1;
  ptr->pedding = -1; // this was supposed to be masked away
}

uint64_t C=0xfffffff;
int main(int argc, char** argv) {
  struct A a;
  foo(&a);
  if ((uint64_t) a.integer > (uint64_t) 0xfffffff) {
    return 1;
  }
  return 0;
}

 "Combine redundant instructions" pass (InstructionCombining.cpp) converts
the statement of  "    if ((uint64_t) a.integer > (uint64_t) 0xfffffff) "
 from
define signext i32 @main(i32 signext, i8**) local_unnamed_addr #1 {
  %3 = alloca %struct.A, align 1
  %4 = bitcast %struct.A* %3 to i8*
  call void @llvm.lifetime.start(i64 7, i8* %4) #3
  call void @foo(%struct.A* %3)
  %5 = getelementptr inbounds %struct.A, %struct.A* %3, i32 0, i32 1
  %6 = bitcast [6 x i8]* %5 to i48*
-----
  %7 = load i48, i48* %6, align 1
  %8 = zext i48 %7 to i64
  %9 = icmp ugt i64 %8, 268435455
----
  br i1 %9, label %10, label %11

to
define signext i32 @main(i32 signext, i8**) local_unnamed_addr #1 {
  %3 = alloca %struct.A, align 1
  %4 = getelementptr inbounds %struct.A, %struct.A* %3, i64 0, i32 0
  call void @llvm.lifetime.start(i64 7, i8* %4) #3
  call void @foo(%struct.A* nonnull %3)
  %5 = getelementptr inbounds %struct.A, %struct.A* %3, i64 0, i32 1
  %6 = bitcast [6 x i8]* %5 to i48*
----
  %7 = load i48, i48* %6, align 1
  %8 = icmp ugt i48 %7, 268435455
-----
  br i1 %8, label %9, label %10


Here the icmp instruction has mismatched data type/length (i48 variable and
i64 constant).  This problem was found when we try to consume the LLVM IR
from LLVM opt.

-- 
Best regards,

Yaoqing Gao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160915/355c1e89/attachment.html>


More information about the llvm-dev mailing list