[RISCV] Failure to use rev8 and 4 byte stores. Possibly due to alignment tracking

[topperc]

With -march=rv32gc_zbb, gcc uses two rev8 instructions and two word sized stores. clang emits shifts and byte stores. https://godbolt.org/z/bWxrnM8rv

#include <stdint.h>
struct a {
  uint64_t b;
  uint8_t block[64];
};
void c(struct a *ctx) {
  uint64_t d = ctx->b;
  (ctx->block + 64 - 8)[0] = d >> 56;
  (ctx->block + 64 - 8)[1] = d >> 48;
  (ctx->block + 64 - 8)[2] = d >> 40;
  (ctx->block + 64 - 8)[3] = d >> 32;
  (ctx->block + 64 - 8)[4] = d >> 24;
  (ctx->block + 64 - 8)[5] = d >> 16;
  (ctx->block + 64 - 8)[6] = d >> 8;
  (ctx->block + 64 - 8)[7] = d;
}

I believe the issue has something to do with determining alignment of the bytes stores. RISC-V requires strict alignment of word stores. The word store would be aligned, but the compiler isn't able to see it.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Craig Topper (topperc)

With -march=rv32gc_zbb, gcc uses two rev8 instructions and two word sized stores. clang emits shifts and byte stores. https://godbolt.org/z/bWxrnM8rv

#include <stdint.h>
struct a {
  uint64_t b;
  uint8_t block[64];
};
void c(struct a *ctx) {
  uint64_t d = ctx->b;
  (ctx->block + 64 - 8)[0] = d >> 56;
  (ctx->block + 64 - 8)[1] = d >> 48;
  (ctx->block + 64 - 8)[2] = d >> 40;
  (ctx->block + 64 - 8)[3] = d >> 32;
  (ctx->block + 64 - 8)[4] = d >> 24;
  (ctx->block + 64 - 8)[5] = d >> 16;
  (ctx->block + 64 - 8)[6] = d >> 8;
  (ctx->block + 64 - 8)[7] = d;
}

I believe the issue has something to do with determining alignment of the bytes stores. RISC-V requires strict alignment of word stores. The word store would be aligned, but the compiler isn't able to see it.

[topperc]

@nikic what can be done to improve reasoning about alignment here? It works with the (64-8) removed from the store address calculation. https://godbolt.org/z/xzT9crKeG

[dtcxzyw]

https://godbolt.org/z/f3MrTM65T
I am confused why we cannot set align 8 for the pointer argument in Clang codegen. It appears that GCC uses this assumption.

If we cannot do this, we can infer the alignment for all uses of %ctx dominated by ctx->b. But it is a bit more complicated...

[dtcxzyw]

https://godbolt.org/z/oG7vsve4T
We can infer the alignment for store in Clang codegen.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Craig Topper (topperc)

With -march=rv32gc_zbb, gcc uses two rev8 instructions and two word sized stores. clang emits shifts and byte stores. https://godbolt.org/z/bWxrnM8rv

#include <stdint.h>
struct a {
  uint64_t b;
  uint8_t block[64];
};
void c(struct a *ctx) {
  uint64_t d = ctx->b;
  (ctx->block + 64 - 8)[0] = d >> 56;
  (ctx->block + 64 - 8)[1] = d >> 48;
  (ctx->block + 64 - 8)[2] = d >> 40;
  (ctx->block + 64 - 8)[3] = d >> 32;
  (ctx->block + 64 - 8)[4] = d >> 24;
  (ctx->block + 64 - 8)[5] = d >> 16;
  (ctx->block + 64 - 8)[6] = d >> 8;
  (ctx->block + 64 - 8)[7] = d;
}

I believe the issue has something to do with determining alignment of the bytes stores. RISC-V requires strict alignment of word stores. The word store would be aligned, but the compiler isn't able to see it.

[dtcxzyw]

llvm-project/clang/lib/CodeGen/CGExpr.cpp

Lines 1446 to 1449 in 503c090

	// Otherwise, use the alignment of the type.
	return CGF.makeNaturalAddressForPointer(
	CGF.EmitScalarExpr(E), E->getType()->getPointeeType(), CharUnits(),
	/*ForPointeeType=*/true, BaseInfo, TBAAInfo, IsKnownNonNull);

The fallback path uses the natural alignment of the decayed type uint8_t.

[nikic]

Does #145733 help?

[topperc]

Does #145733 help?

Yes it does