[LLVMdev] Performance regression on ARM

[Saleem Abdulrasool]

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
> __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
> <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>