[llvm-dev] [GSoC 2016] Code Generation Improvements task

[Tim Northover via llvm-dev]

Hi Vivek,

(Mostly responding with AArch64 hints, though anything I happen to
know from elsewhere too).

On 29 February 2016 at 13:00, vivek pandya via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>  2. lib/Target/AArch64/AArch64AddressTypePromotion.cpp
> As far as I understand this pass promotes sign exertion for 32 bit integer (
> address) and performs calculation on 64 bit number thus processes need not
> switch execution mode to 32 bit.

Switching execution mode isn't an option on AArch64 (it can only
happen with OS support and never happens within a single process on a
sane OS).

This pass is more a matter of putting the IR in a form that precisely
matches the addressing modes that are actually available. AArch64 can
encode addresses like "base64 + sext(offset32)" into the actual
load/store instruction so it's advantageous to put the sext as close
as possible to the pointer dereference.

I'm afraid I don't really know enough about other architectures to say
which could benefit. It's obviously only beneficial if they have the
addressing modes to support it.

> 3. lib/Target/AArch64/AArch64PromoteConstant.cpp
> This pass tries to simplify aggregate data like struct of const with special
> SIMD instructions available on the system. For example on ARM its NEON
> similarly other architectures have SIMD support specifically MIPS, IBM
> System Z, Power PC with MMX/AltiVee and x86 with Intel’s AVX.

Possibly. It seems to rely pretty strongly on ARM's "load more than
you can actually use" instructions: vldN instructions can load up to 4
128-bit vectors, but they can still only be used as 128-bit vectors.
If other targets possess similar, then they could well benefit; if
not, then it's probably pointless.

> I have question regarding Target hooks. Does it means using TargetInfo an
> SubTargetInfo class and at runtime decide architecture type and based on
> that perform optimization ( i.e use target specific instructions ) ?

I think they more normally live in TargetTransformInfo.

> Please help me ! Am I going in right direction ? Suggest some code ,
> document to look for further ideas. Also if any one like to mentor me for
> this project.

It sounds like a plausible direction, but documentation is always
lacking in these kinds of things.

As a complete outsider to targets with delay slots, merging their
logic sounds like a nice improvement to me (especially as Lanai is
probably incoming as another ISA that has decided delay slots are a
good idea). But (also as an outsider) I have no idea how practical
that really is.

Cheers.

Tim.