<div dir="ltr"><div>Hello, I'm new to this mailing list and fixing llvm bugs for Android.</div><div><br></div><div>Can anyone point me to any previous discussion or work related to the following bug?</div><div>  <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23897&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=SjsgLUBuP4Z6NNIkbNNTqoKFkttYEp5JU7ELxsDERBE&s=ziHImD5Gi87al7wg7i6W2cNXigCEwzKGm_0JFTD2GcI&e=">https://llvm.org/bugs/show_bug.cgi?id=23897</a></div><div><br></div><div>I am testing my patch to llvm to make f128 values stay in SSE registers instead of being split into two i64 values. I have tried to add a register class FR128 to hold f128 values for the x86_64 target. Preliminary tests seem to be working and compatible with gcc's __float128 long double type.</div><div><br></div><div>I found that long double complex (with two f128 values) also have calling convention compatibility problem with gcc and can be fixed similarly.</div><div>My current patch does change quite a few places in type legalizing pass and some other optimizations related to f128 or i128 values. A few changes in the softening of floating point types to keep some f128 typed IR and convert some f128 opcode to library function calls.</div><div><br></div><div>Has anyone tried this approach or have other solution?</div><div><br></div><div>Thanks</div><div><br></div><div>-- Chih-Hung</div><div><br></div></div>