[llvm-commits] [PATCH] AArch64 backend: LLVM changes

Tim Northover t.p.northover at gmail.com
Sat Jan 12 04:36:39 PST 2013


Hi Renato,

Thanks for taking a look. I agree it could drive people insane.

> Have you run the build and check-all on an ARM32 system?

Actually, I haven't. It's a good idea (though it does sound a little
parochial: why not PPC, MIPS, ... too? Because we don't have the
hardware, I suppose). I'll do that on Monday.

> Now to code specific questions:
>
> +// Vector Multiply-subtract (Floating Point)
> +def int_aarch64_neon_vfms : Neon_3Arg_Intrinsic;
> (...)
> +// Vector Multiply Extended (Floating Point)
> +def int_aarch64_neon_vmulx : Neon_2Arg_Intrinsic;
>
> Can't these be patterns?

Almost certainly not vmulx. Its semantics are "like fmul except 0 *
infinity = 2".

However, vfms could be (and actually does have patterns too). It was
probably the path of least resistance for Clang, but that can be
changed easily enough.

> -      APFloat apf(APInt::getNullValue(VT.getSizeInBits()));
> +      APFloat apf(APInt::getNullValue(VT.getSizeInBits()), /*isIEEE=*/
> true);
>
> I thought you had changed APFloat...

It's in review, but I haven't rebased the backend on still-uncertain code yet.

> -        ? dwarf::DW_EH_PE_udata4 : dwarf::DW_EH_PE_absptr;
> +         ? dwarf::DW_EH_PE_udata4 : dwarf::DW_EH_PE_absptr;
>
> unnecessary space change, might confuse history

Thanks. I'll fix that.

Tim.



More information about the llvm-commits mailing list