[LLVMdev] Performance regression on ARM

[Anton Korobeynikov]

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
<compnerd at compnerd.org> wrote:
> 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



-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University