<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><i><font size="2" face="monospace, monospace"><b>Vivek Pandya</b></font></i><div><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Mar 1, 2016 at 10:23 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vivek,<br>
<br>
(Mostly responding with AArch64 hints, though anything I happen to<br>
know from elsewhere too).<br>
<br>
On 29 February 2016 at 13:00, vivek pandya via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>  2. lib/Target/AArch64/AArch64AddressTypePromotion.cpp<br>
> As far as I understand this pass promotes sign exertion for 32 bit integer (<br>
> address) and performs calculation on 64 bit number thus processes need not<br>
> switch execution mode to 32 bit.<br>
<br>
</span>Switching execution mode isn't an option on AArch64 (it can only<br>
happen with OS support and never happens within a single process on a<br>
sane OS).<br>
<br>
This pass is more a matter of putting the IR in a form that precisely<br>
matches the addressing modes that are actually available. AArch64 can<br>
encode addresses like "base64 + sext(offset32)" into the actual<br>
load/store instruction so it's advantageous to put the sext as close<br>
as possible to the pointer dereference.<br>
<br>
I'm afraid I don't really know enough about other architectures to say<br>
which could benefit. It's obviously only beneficial if they have the<br>
addressing modes to support it.<br>
<span class=""><br>
> 3. lib/Target/AArch64/AArch64PromoteConstant.cpp<br>
> This pass tries to simplify aggregate data like struct of const with special<br>
> SIMD instructions available on the system. For example on ARM its NEON<br>
> similarly other architectures have SIMD support specifically MIPS, IBM<br>
> System Z, Power PC with MMX/AltiVee and x86 with Intel’s AVX.<br>
<br>
</span>Possibly. It seems to rely pretty strongly on ARM's "load more than<br>
you can actually use" instructions: vldN instructions can load up to 4<br>
128-bit vectors, but they can still only be used as 128-bit vectors.<br>
If other targets possess similar, then they could well benefit; if<br>
not, then it's probably pointless.<br>
<span class=""><br>
> I have question regarding Target hooks. Does it means using TargetInfo an<br>
> SubTargetInfo class and at runtime decide architecture type and based on<br>
> that perform optimization ( i.e use target specific instructions ) ?<br>
<br>
</span>I think they more normally live in TargetTransformInfo.<br>
<span class=""><br>
> Please help me ! Am I going in right direction ? Suggest some code ,<br>
> document to look for further ideas. Also if any one like to mentor me for<br>
> this project.<br>
<br>
</span>It sounds like a plausible direction, but documentation is always<br>
lacking in these kinds of things.<br>
<br>
As a complete outsider to targets with delay slots, merging their<br>
logic sounds like a nice improvement to me (especially as Lanai is<br>
probably incoming as another ISA that has decided delay slots are a<br>
good idea). But (also as an outsider) I have no idea how practical<br>
that really is.<br></blockquote><div><br></div><div>Thanks Tim for providing more insights, I would gather more information in given direction. Further more here mentioned 3 tasks may be not a much work for some one who has a good grasp on llvm but for me it may be sufficient for GSoC duration. It may not be possible for Google to provide fundings for limited number of improvements. So I am thinking to include some TODOs in StackColoring.cpp and StackSlotColoring.cpp in proposal too. Will it be enough to demonstrate in proposal ? </div><div><br></div><div>Still I am looking for feedback on RDF part and also if some one is willing to mentor me.</div><div><br></div><div>Sincerely,</div><div>Vivek</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>