[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