Please use GitHub pull requests for new patches. Avoid migrating existing patches. Phabricator shutdown timeline

In D157694#4584915, @asb wrote:

Thanks for catching this. It looks like if you do e.g. .LBB0-16 it will just underflow - do other targets do anything smarter here?

Aug 14 2023, 11:15 PM · Restricted Project, Restricted Project

Aug 11 2023

Yunzezhu requested review of D157694: [RISCV][MC]Add support for Binary MCExpr.

Aug 11 2023, 2:52 AM · Restricted Project, Restricted Project

Aug 9 2023

Yunzezhu committed rG5f73d2b780a8: [RISCV] Enable alias analysis by default (authored by Yunzezhu).

[RISCV] Enable alias analysis by default

Aug 9 2023, 7:55 PM · Restricted Project, Restricted Project

Yunzezhu closed D157250: [RISCV] Enable alias analysis by default.

Aug 9 2023, 7:54 PM · Restricted Project, Restricted Project

Aug 7 2023

Yunzezhu added inline comments to D157250: [RISCV] Enable alias analysis by default.

Aug 7 2023, 8:20 PM · Restricted Project, Restricted Project

Yunzezhu updated the diff for D157250: [RISCV] Enable alias analysis by default.

Added cl::opt for useAA.

Aug 7 2023, 8:19 PM · Restricted Project, Restricted Project

Aug 6 2023

Yunzezhu requested review of D157250: [RISCV] Enable alias analysis by default.

Aug 6 2023, 7:53 PM · Restricted Project, Restricted Project

Jun 29 2023

Yunzezhu committed rG9d22b54d6b21: [RISCV] Use temporary stack in expanding SPLAT_VECTOR_SPLIT_I64_VL node (authored by Yunzezhu).

[RISCV] Use temporary stack in expanding SPLAT_VECTOR_SPLIT_I64_VL node

Jun 29 2023, 1:51 AM · Restricted Project, Restricted Project

Yunzezhu closed D153743: [RISCV] Use temporary stack in expanding SPLAT_VECTOR_SPLIT_I64_VL node.

Jun 29 2023, 1:51 AM · Restricted Project, Restricted Project

Jun 26 2023

Yunzezhu added a comment to D153743: [RISCV] Use temporary stack in expanding SPLAT_VECTOR_SPLIT_I64_VL node.

In D153743#4447973, @craig.topper wrote:

Does mean scalar FP code we copied the frame index from also has this bug?

Jun 26 2023, 4:33 AM · Restricted Project, Restricted Project

Yunzezhu updated the diff for D153743: [RISCV] Use temporary stack in expanding SPLAT_VECTOR_SPLIT_I64_VL node.

Updated some affected test cases.

Jun 26 2023, 4:28 AM · Restricted Project, Restricted Project

Yunzezhu requested review of D153743: [RISCV] Use temporary stack in expanding SPLAT_VECTOR_SPLIT_I64_VL node.

Jun 26 2023, 12:51 AM · Restricted Project, Restricted Project

Jun 7 2023

Yunzezhu abandoned D152250: [Clang][RISCV] Add test cases for intrinsics clz/ctz codegen when has extension zbb/xtheadbb.

Abandon this revision because https://reviews.llvm.org/D151867 is abandoned.

Jun 7 2023, 8:02 PM · Restricted Project, Restricted Project

Yunzezhu abandoned D151867: [Clang][RISCV] Make generic clz/ctz builtins defined for zero on RISCV targets..

In D151867#4401987, @craig.topper wrote:

In D151867#4401952, @Yunzezhu wrote:

In D151867#4400255, @craig.topper wrote:

From the C language perspective with this change, __builtin_clz/ctz is still considered undefined for 0 and code that uses it is ill-formed. isCLZForZeroUndef is only intended to prevent the middle end from optimizing based on the undefinedness and creating surprises. See also https://discourse.llvm.org/t/should-ubsan-detect-0-input-to-builtin-clz-ctz-regardless-of-target/71060

I see builtin_clz/ctz returning an undefined value for 0 input matches gcc's document, but when I test builtin_clz/ctz with 0 input on gcc, it returns a valid value rather than an undefined value. It looks gcc does not follow gcc's document. I'm not sure which one is better that match document to return undefined for 0, or match gcc's behavior to return defined value?

From what I can see in the assembly here https://godbolt.org/z/s4qqz83EK, gcc's undefined behavior sanitizer does consider an input of 0 to be undefined.

Jun 7 2023, 8:01 PM · Restricted Project, Restricted Project

Jun 6 2023

Yunzezhu added a comment to D151867: [Clang][RISCV] Make generic clz/ctz builtins defined for zero on RISCV targets..

In D151867#4400255, @craig.topper wrote:

From the C language perspective with this change, __builtin_clz/ctz is still considered undefined for 0 and code that uses it is ill-formed. isCLZForZeroUndef is only intended to prevent the middle end from optimizing based on the undefinedness and creating surprises. See also https://discourse.llvm.org/t/should-ubsan-detect-0-input-to-builtin-clz-ctz-regardless-of-target/71060

Jun 6 2023, 8:29 PM · Restricted Project, Restricted Project

Yunzezhu added a comment to D151867: [Clang][RISCV] Make generic clz/ctz builtins defined for zero on RISCV targets..

In D151867#4398483, @asb wrote:

Could you please post a separate patch that has a test that will show the codegen change (and demonstrate how it is unchanged when zbb or xtheadbb)?

Jun 6 2023, 2:30 AM · Restricted Project, Restricted Project

Yunzezhu requested review of D152250: [Clang][RISCV] Add test cases for intrinsics clz/ctz codegen when has extension zbb/xtheadbb.

Jun 6 2023, 2:28 AM · Restricted Project, Restricted Project

Yunzezhu updated the diff for D151867: [Clang][RISCV] Make generic clz/ctz builtins defined for zero on RISCV targets..

I made the flag isCLZForZeroUndef set to false only when target support extension zbb or xtheadbb, and this will prevent making codegen worse when target does not support abb or xtheadbb.

Jun 6 2023, 12:09 AM · Restricted Project, Restricted Project