[LLVMdev] Performance regression on ARM (original) (raw)

Saleem Abdulrasool compnerd at compnerd.org
Mon Oct 20 19:28:09 PDT 2014

On Sun, Oct 19, 2014 at 6:54 AM, Anton Korobeynikov <anton at korobeynikov.info

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 _cxathrow, 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 <anton at korobeynikov.info> 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 >> <anton at korobeynikov.info> 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 LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141020/2b472692/attachment.html>

More information about the llvm-dev mailing list