After a second look, the transformation looks right since "268435455"
can
be fit into i48. Thanks.
On Thu, Sep 15, 2016 at 9:49 AM, Yaoqing Gao <yaoqing.gao at gmail.com>
wrote:
> 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
>
--
Best regards,
Yaoqing Gao
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160915/df65a966/attachment.html>