[CIR][CodeGen][Bugfix] generate field index with respect to layout #263

gitoleg · 2023-09-18T14:26:12Z

There is a bug in the code generation: the field index for the GetMemberOp is taken from the FieldDecl, with no respect to the record layout. One of the manifestation of the bug is the wrong index generated for a field in a derived class that does not take into the account the instance of the base class (that has index 0).

You can take a look at the example in test/CIR/CodeGen/derived-to-base.cpp, i.e. the current test is not the correct one

// CHECK-DAG: !ty_22C23A3ALayer22 = !cir.struct<class "C2::Layer" {!ty_22C13A3ALayer22, !cir.ptr<!ty_22C222>
// CHECK-DAG: !ty_22C33A3ALayer22 = !cir.struct<struct "C3::Layer" {!ty_22C23A3ALayer22

// CHECK: cir.func @_ZN2C35Layer10InitializeEv

// CHECK:  cir.scope {
// CHECK:    %2 = cir.base_class_addr(%1 : cir.ptr <!ty_22C33A3ALayer22>) -> cir.ptr <!ty_22C23A3ALayer22>
// CHECK:    %3 = cir.get_member %2[0] {name = "m_C1"} : !cir.ptr<!ty_22C23A3ALayer22> -> !cir.ptr<!cir.ptr<!ty_22C222>>

As one can see, the result (of ptr type to !ty_22C222 ) must have the index 1 in the corresponded struct ty_22C23A3ALayer22.

Basically the same is done in the clang/CodeGen/CGExpr.cpp, so we don't invent something new here.

Note, this fix doesn't affect anything related to the usage of buildPreserveStructAccess where the field->getFieldIndex() is used.

htyu

LGTM, thanks for the fix!

bcardosolopes · 2023-09-19T00:58:48Z

Awesome, LGTM.

Btw, what about other uses of getFieldIndex() in the CIR codebase, do any other of them need to be patched too?

gitoleg · 2023-09-20T09:35:03Z

@bcardosolopes I take a look at, it's not clear from the first glance if they need or need not

#270) This is a minor fix similar to the one introduced in #263. Basically, all calls to the `buildLValueForFieldInitialization` are even with the origin codegen `emitLValueForFieldInitialization` calls, i.e. the field index is calculated from the record layout, but not from the decl `field->getFieldIndex()`. Added just one test, because looks like we need to implement some `NYI` features first to test another places e.g. in `CIRGenExprAgg.cpp`, though I could miss something. Anyway, given the original codegen doesn't use `getFieldIndex` in these places, we also should not. All the remaining usages of `getFieldIndex` are ok.

) There is a bug in the code generation: the field index for the `GetMemberOp` is taken from the `FieldDecl`, with no respect to the record layout. One of the manifestation of the bug is the wrong index generated for a field in a derived class that does not take into the account the instance of the base class (that has index 0). You can take a look at the example in `test/CIR/CodeGen/derived-to-base.cpp`, i.e. the current test is not the correct one ``` // CHECK-DAG: !ty_22C23A3ALayer22 = !cir.struct<class "C2::Layer" {!ty_22C13A3ALayer22, !cir.ptr<!ty_22C222> // CHECK-DAG: !ty_22C33A3ALayer22 = !cir.struct<struct "C3::Layer" {!ty_22C23A3ALayer22 // CHECK: cir.func @_ZN2C35Layer10InitializeEv // CHECK: cir.scope { // CHECK: %2 = cir.base_class_addr(%1 : cir.ptr <!ty_22C33A3ALayer22>) -> cir.ptr <!ty_22C23A3ALayer22> // CHECK: %3 = cir.get_member %2[0] {name = "m_C1"} : !cir.ptr<!ty_22C23A3ALayer22> -> !cir.ptr<!cir.ptr<!ty_22C222>> ``` As one can see, the result (of ptr type to `!ty_22C222` ) must have the index `1` in the corresponded struct `ty_22C23A3ALayer22`. Basically the same is done in the `clang/CodeGen/CGExpr.cpp`, so we don't invent something new here. Note, this fix doesn't affect anything related to the usage of `buildPreserveStructAccess` where the `field->getFieldIndex()` is used.

#270) This is a minor fix similar to the one introduced in #263. Basically, all calls to the `buildLValueForFieldInitialization` are even with the origin codegen `emitLValueForFieldInitialization` calls, i.e. the field index is calculated from the record layout, but not from the decl `field->getFieldIndex()`. Added just one test, because looks like we need to implement some `NYI` features first to test another places e.g. in `CIRGenExprAgg.cpp`, though I could miss something. Anyway, given the original codegen doesn't use `getFieldIndex` in these places, we also should not. All the remaining usages of `getFieldIndex` are ok.

) There is a bug in the code generation: the field index for the `GetMemberOp` is taken from the `FieldDecl`, with no respect to the record layout. One of the manifestation of the bug is the wrong index generated for a field in a derived class that does not take into the account the instance of the base class (that has index 0). You can take a look at the example in `test/CIR/CodeGen/derived-to-base.cpp`, i.e. the current test is not the correct one ``` // CHECK-DAG: !ty_22C23A3ALayer22 = !cir.struct<class "C2::Layer" {!ty_22C13A3ALayer22, !cir.ptr<!ty_22C222> // CHECK-DAG: !ty_22C33A3ALayer22 = !cir.struct<struct "C3::Layer" {!ty_22C23A3ALayer22 // CHECK: cir.func @_ZN2C35Layer10InitializeEv // CHECK: cir.scope { // CHECK: %2 = cir.base_class_addr(%1 : cir.ptr <!ty_22C33A3ALayer22>) -> cir.ptr <!ty_22C23A3ALayer22> // CHECK: %3 = cir.get_member %2[0] {name = "m_C1"} : !cir.ptr<!ty_22C23A3ALayer22> -> !cir.ptr<!cir.ptr<!ty_22C222>> ``` As one can see, the result (of ptr type to `!ty_22C222` ) must have the index `1` in the corresponded struct `ty_22C23A3ALayer22`. Basically the same is done in the `clang/CodeGen/CGExpr.cpp`, so we don't invent something new here. Note, this fix doesn't affect anything related to the usage of `buildPreserveStructAccess` where the `field->getFieldIndex()` is used.

#270) This is a minor fix similar to the one introduced in #263. Basically, all calls to the `buildLValueForFieldInitialization` are even with the origin codegen `emitLValueForFieldInitialization` calls, i.e. the field index is calculated from the record layout, but not from the decl `field->getFieldIndex()`. Added just one test, because looks like we need to implement some `NYI` features first to test another places e.g. in `CIRGenExprAgg.cpp`, though I could miss something. Anyway, given the original codegen doesn't use `getFieldIndex` in these places, we also should not. All the remaining usages of `getFieldIndex` are ok.

) There is a bug in the code generation: the field index for the `GetMemberOp` is taken from the `FieldDecl`, with no respect to the record layout. One of the manifestation of the bug is the wrong index generated for a field in a derived class that does not take into the account the instance of the base class (that has index 0). You can take a look at the example in `test/CIR/CodeGen/derived-to-base.cpp`, i.e. the current test is not the correct one ``` // CHECK-DAG: !ty_22C23A3ALayer22 = !cir.struct<class "C2::Layer" {!ty_22C13A3ALayer22, !cir.ptr<!ty_22C222> // CHECK-DAG: !ty_22C33A3ALayer22 = !cir.struct<struct "C3::Layer" {!ty_22C23A3ALayer22 // CHECK: cir.func @_ZN2C35Layer10InitializeEv // CHECK: cir.scope { // CHECK: %2 = cir.base_class_addr(%1 : cir.ptr <!ty_22C33A3ALayer22>) -> cir.ptr <!ty_22C23A3ALayer22> // CHECK: %3 = cir.get_member %2[0] {name = "m_C1"} : !cir.ptr<!ty_22C23A3ALayer22> -> !cir.ptr<!cir.ptr<!ty_22C222>> ``` As one can see, the result (of ptr type to `!ty_22C222` ) must have the index `1` in the corresponded struct `ty_22C23A3ALayer22`. Basically the same is done in the `clang/CodeGen/CGExpr.cpp`, so we don't invent something new here. Note, this fix doesn't affect anything related to the usage of `buildPreserveStructAccess` where the `field->getFieldIndex()` is used.

#270) This is a minor fix similar to the one introduced in #263. Basically, all calls to the `buildLValueForFieldInitialization` are even with the origin codegen `emitLValueForFieldInitialization` calls, i.e. the field index is calculated from the record layout, but not from the decl `field->getFieldIndex()`. Added just one test, because looks like we need to implement some `NYI` features first to test another places e.g. in `CIRGenExprAgg.cpp`, though I could miss something. Anyway, given the original codegen doesn't use `getFieldIndex` in these places, we also should not. All the remaining usages of `getFieldIndex` are ok.

) There is a bug in the code generation: the field index for the `GetMemberOp` is taken from the `FieldDecl`, with no respect to the record layout. One of the manifestation of the bug is the wrong index generated for a field in a derived class that does not take into the account the instance of the base class (that has index 0). You can take a look at the example in `test/CIR/CodeGen/derived-to-base.cpp`, i.e. the current test is not the correct one ``` // CHECK-DAG: !ty_22C23A3ALayer22 = !cir.struct<class "C2::Layer" {!ty_22C13A3ALayer22, !cir.ptr<!ty_22C222> // CHECK-DAG: !ty_22C33A3ALayer22 = !cir.struct<struct "C3::Layer" {!ty_22C23A3ALayer22 // CHECK: cir.func @_ZN2C35Layer10InitializeEv // CHECK: cir.scope { // CHECK: %2 = cir.base_class_addr(%1 : cir.ptr <!ty_22C33A3ALayer22>) -> cir.ptr <!ty_22C23A3ALayer22> // CHECK: %3 = cir.get_member %2[0] {name = "m_C1"} : !cir.ptr<!ty_22C23A3ALayer22> -> !cir.ptr<!cir.ptr<!ty_22C222>> ``` As one can see, the result (of ptr type to `!ty_22C222` ) must have the index `1` in the corresponded struct `ty_22C23A3ALayer22`. Basically the same is done in the `clang/CodeGen/CGExpr.cpp`, so we don't invent something new here. Note, this fix doesn't affect anything related to the usage of `buildPreserveStructAccess` where the `field->getFieldIndex()` is used.

#270) This is a minor fix similar to the one introduced in #263. Basically, all calls to the `buildLValueForFieldInitialization` are even with the origin codegen `emitLValueForFieldInitialization` calls, i.e. the field index is calculated from the record layout, but not from the decl `field->getFieldIndex()`. Added just one test, because looks like we need to implement some `NYI` features first to test another places e.g. in `CIRGenExprAgg.cpp`, though I could miss something. Anyway, given the original codegen doesn't use `getFieldIndex` in these places, we also should not. All the remaining usages of `getFieldIndex` are ok.

…lvm#263) There is a bug in the code generation: the field index for the `GetMemberOp` is taken from the `FieldDecl`, with no respect to the record layout. One of the manifestation of the bug is the wrong index generated for a field in a derived class that does not take into the account the instance of the base class (that has index 0). You can take a look at the example in `test/CIR/CodeGen/derived-to-base.cpp`, i.e. the current test is not the correct one ``` // CHECK-DAG: !ty_22C23A3ALayer22 = !cir.struct<class "C2::Layer" {!ty_22C13A3ALayer22, !cir.ptr<!ty_22C222> // CHECK-DAG: !ty_22C33A3ALayer22 = !cir.struct<struct "C3::Layer" {!ty_22C23A3ALayer22 // CHECK: cir.func @_ZN2C35Layer10InitializeEv // CHECK: cir.scope { // CHECK: %2 = cir.base_class_addr(%1 : cir.ptr <!ty_22C33A3ALayer22>) -> cir.ptr <!ty_22C23A3ALayer22> // CHECK: %3 = cir.get_member %2[0] {name = "m_C1"} : !cir.ptr<!ty_22C23A3ALayer22> -> !cir.ptr<!cir.ptr<!ty_22C222>> ``` As one can see, the result (of ptr type to `!ty_22C222` ) must have the index `1` in the corresponded struct `ty_22C23A3ALayer22`. Basically the same is done in the `clang/CodeGen/CGExpr.cpp`, so we don't invent something new here. Note, this fix doesn't affect anything related to the usage of `buildPreserveStructAccess` where the `field->getFieldIndex()` is used.

llvm#270) This is a minor fix similar to the one introduced in llvm#263. Basically, all calls to the `buildLValueForFieldInitialization` are even with the origin codegen `emitLValueForFieldInitialization` calls, i.e. the field index is calculated from the record layout, but not from the decl `field->getFieldIndex()`. Added just one test, because looks like we need to implement some `NYI` features first to test another places e.g. in `CIRGenExprAgg.cpp`, though I could miss something. Anyway, given the original codegen doesn't use `getFieldIndex` in these places, we also should not. All the remaining usages of `getFieldIndex` are ok.