LGTM but this will need to be reviewed by someone familiar with libc++ of course =).

• Implement getAsStr()
• Naming Changes.

Autogenerate more, but still not all, affected codegen tests.

I think because I use the

I'm sorry to be late to reply.
I'm making small tests and some code changes to demonstrate the following:

Split off addresstaken fixes.

LGTM, but please drop the "use poison instead of undef" comments -- I don't think using poison instead of undef for dead code requires any explicit justification.

Update patch to:

I think this change broke apt.llvm.org

Since this commit, llvm (main branch) cannot be built with some GNU compilers such as 8.3.1 (provided by RHEL8), 9.3.0 (provided by OpenHPC).
It works fine with 10.2.0 and higher though.

rebase

Sync up; moved DeclFilter to ClangTidy.cpp.

In D104440#2829220, @LuoYuanke wrote:

With -O0, the small case can also generate "IMPLICIT_DEF" and "CHS_Fp80". I think we are near to the root cause. Stay tuned.

With -O0, the small case can also generate "IMPLICIT_DEF" and "CHS_Fp80". I think we are near to the root cause. Stay tuned.

Remove the update at createOverflowTuple

Are you running the large and small cases the same way? Have looked at the SelectionDAG debug logs for the affected basic block in the large case?

I was able to trigger the error with llc -O2 -fast-isel on a simple test. So that is a path to create this but you haven’t answered if fast isel is being used in your case.

In D104440#2829198, @LuoYuanke wrote:

I don’t know what llvm-extract —recursive does. I’ve only used -func to extract a single function I knew caused a compiler crash.

Converting IMPLICIT_DEF to undef flag is correct.

IMPLICIT_DEF can get created from ISD::UNDEF but as far I could see ISD::UNDEF for fp80 is supposed to Expand to ConstantFP 0.

I also think fneg of undef should be folded by getNode when it is created in SelectionDAGBuilder. Is this going through fast isel or something?

In my small test case that is extracted by llvm-extract, the "fneg contract x86_fp80 undef" is lowered to "LD_Fp080". But in the big case which cause crash, it is lowered to "IMPLICIT_DEF" and "CHS_Fp80".

76:                                               ; preds = %74
  %77 = call contract x86_fp80 @_ZN5boost4math8policies20raise_overflow_errorIeNS1_6policyINS1_13promote_floatILb0EEENS1_14promote_doubleILb0EEENS1_14default_policyES8_S8_S8_S8_S8_S8_S8_S8_S8_S8_EEEET_PKcSC_RKT0_(i8* getelementptr inbounds ([29 x i8], [29 x i8]* @.str.3.16422, i64 0, i64 0), i8* null, %"struct.std::__atomic_flag_base"* nonnull align 1 dereferenceable(1) %9)
  %78 = fneg contract x86_fp80 undef
  br label %121

CALL64pcrel32 @_ZN5boost4math8policies20raise_overflow_errorIeNS1_6policyINS1_13promote_floatILb0EEENS1_14promote_doubleILb0EEENS1_14default_policyES8_S8_S8_S8_S8_S8_S8_S8_S8_S8_EEEET_PKcSC_RKT0_, <regmask $bh $bl $bp $bph $bpl $bx $ebp $ebx $hbp $hbx $rbp $rbx $r12 $r13 $r14 $r15 $r12b $r13b $r14b $r15b $r12bh $r13bh $r14bh $r15bh $r12d $r13d $r14d $r15d $r12w $r13w $r14w $r15w $r12wh and 3 more...>, implicit $rsp, implicit $ssp, implicit $rdi, implicit $rsi, implicit $rdx, implicit-def $rsp, implicit-def $ssp, implicit-def $fp0
ADJCALLSTACKUP64 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp
%118:rfp80 = COPY $fp0
%13:rfp80 = nofpexcept LD_Fp080 implicit-def dead $fpsw, implicit $fpcw

In D104440#2829202, @craig.topper wrote:

In D104440#2829199, @LuoYuanke wrote:

BTW, do you think the patch to handle undef case in stackify pass reasonable?

No I do not. I have no reason to believe fneg or one arg instructions are the only things that could be effected. We need to understand why this is happening because isel was trying to prevent this.

In D104440#2829199, @LuoYuanke wrote:

BTW, do you think the patch to handle undef case in stackify pass reasonable?

Complex hierarchy caused this to be merged by @ldionne on behalf of @cjdb and @zoecarver.

BTW, do you think the patch to handle undef case in stackify pass reasonable?

I don’t know what llvm-extract —recursive does. I’ve only used -func to extract a single function I knew caused a compiler crash.

Converting IMPLICIT_DEF to undef flag is correct.

IMPLICIT_DEF can get created from ISD::UNDEF but as far I could see ISD::UNDEF for fp80 is supposed to Expand to ConstantFP 0.

I also think fneg of undef should be folded by getNode when it is created in SelectionDAGBuilder. Is this going through fast isel or something?