The main problem with intrinsic is that ABI for _Complex is defined by
C. Therefore it's unclear to me which signature the intrinsic should
have and how we "lift" the ABI differences (e.g. consider the case
when C ABI would require us to pass _Complex float as { float, float }
on one platform and unwrapped float, float on another platform) ...On Tue, Oct 21, 2014 at 6:28 AM, Saleem Abdulrasool <[email protected]> wrote: > On Sun, Oct 19, 2014 at 6:54 AM, Anton Korobeynikov > <[email protected]> wrote: >> >> I feel like opening a can full of worms here. Here is full story: >> >> 1. On ARM all the EABI library functions need to use AAPCS calling >> convention even on hard floating point targets >> 2. __mulsc3, __muldc3 and friends are not defined by EABI, however >> both compiler-rt and libgcc emit them with AAPCS, not AAPCS-VFP >> calling convention >> >> Right now clang creates calls to __mul?c3 routines, but uses C calling >> convention, which on hard FP targets got translated into AAPCS-VFP CC, >> which is certainly not what the implementation expects. >> >> The obvious fix is to make sure clang specifies proper calling >> convention for such calls. And here we have plenty of funny details. >> >> 1. There is CodeGenModule::CreateRuntimeFunction() which is used to >> emit calls to runtime functions. Surely, we cannot use it here, >> because we would not like to force calling convention on routines like >> __cxa_throw, etc. (while they are not using and FP arguments and >> technically it's safe for ARM, but...) >> 2. Even more CodeGenModule::CreateRuntimeFunction() itself is not >> enough. The reason is that we need to specify a calling convention on >> *both* call and function. Usually we're using >> CodeGenFunction::EmitRuntimeCall() simply because creating a function >> requires one to specify LLVM calling convention and >> CodeGenFunction::CreateCall() expects clang's calling convention ;) >> 3. So, for now I decided to separate calling conventions used to emit >> calls to runtime functions and compiler builtins. >> >> Some patch which shows this approach (and the whole problem) is attached >> :) > > > I think I would agree with Tim on this. The intrinsic approach would be > nicer. The actual calling convention and function name information is > handled in the lowering, and even correctly switches between various ones. > This also affords us flexibility in the various functions the target runtime > library supports. The alternative would be to hoist that knowledge in > clang, but that would be problematic for cases of JIT. > >> >> On Sat, Oct 18, 2014 at 3:27 PM, Anton Korobeynikov >> <[email protected]> wrote: >> > Hi Chandler, >> > >> > That's embarrassing how weird this part of clang is. I have a >> > provisional >> > patch which fixes the problem but underlines clang's problems. I will >> > submit >> > it tonight for comments. >> > >> > суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: >> > >> >> >> >> On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov >> >> <[email protected]> wrote: >> >>> >> >>> > Chandler’s complex arithmetic changes are also in the range: r219557 >> >>> > in >> >>> > clang. We saw it change the code in mandel-2 significantly. >> >>> mandel-2 is broken on hard FP ABI systems, btw. The reason is simply: >> >>> we're emitting a call to __muldc3 with AAPCS VFP calling convention, >> >>> however, the function expects softfp (AAPCS) calling conv and reads >> >>> garbage from GP registers. >> >>> >> >>> I'm working on fix. >> >> >> >> >> >> Thanks for looking at this Anton. >> >> >> >> I don't really know what signal should be used here. Several initial >> >> attempts at this didn't work because of ABI and calling convention >> >> issues >> >> and I thought I had figured out a sound solution by directly forming >> >> and >> >> calling the library routines using Clang's code generation to handle >> >> all of >> >> the ABI issues.... but apparently not. >> >> >> >> If you need to back out the patch temporarily or take any other steps >> >> to >> >> mitigate, by all means. =/ Sorry for the fallout. >> > >> > >> > >> > -- >> > With best regards, Anton Korobeynikov >> > Faculty of Mathematics and Mechanics, Saint Petersburg State University >> > >> >> >> >> -- >> With best regards, Anton Korobeynikov >> Faculty of Mathematics and Mechanics, Saint Petersburg State University >> >> _______________________________________________ >> LLVM Developers mailing list >> [email protected] http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
