similar to: [GSoC 2016] Code Generation Improvements task

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

*Vivek Pandya* On Tue, Mar 1, 2016 at 10:23 AM, Tim Northover <t.p.northover at gmail.com> wrote: > 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.

On 3/1/2016 11:26 AM, vivek pandya via llvm-dev wrote: > > Still I am looking for feedback on RDF part and also if some one is > willing to mentor me. Hi Vivek, Sorry, I missed this email. I wrote the RDF stuff and I'd be happy to help you out with it if you are interested. The idea was to have a utility class that would represent the data flow between registers. The registers

AArch64AddressTypePromotion.cpp does a fair bit of work to help make these things work out well. It could probably be generalized for non-AArch64 targets as per the comment in the file header. > On Jun 26, 2014, at 10:42 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > Cool HW trick. :) > Are those 'sxtw' ops free? > That’ll depend on the details of the

*Vivek Pandya* On Wed, Mar 23, 2016 at 10:28 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 3/1/2016 11:26 AM, vivek pandya via llvm-dev wrote: > >> >> Still I am looking for feedback on RDF part and also if some one is >> willing to mentor me. > > Hello Krzysztof Parrzyszek, I switched to other topic as I felt I don't have enough

Hi, As a follow up to Patch D23646 <https://reviews.llvm.org/D23646>, I'm trying to figure out if there should be an alignment check and what the correct approach is. Some background: For stores, the pass turns: %i.vec = shuffle <8 x i32> %v0, <8 x i32> %v1, <0, 4, 8, 1, 5, 9, 2, 6, 10, 3, 7, 11> store <12 x i32> %i.vec, <12 x i32>* %ptr

----- Original Message ----- > From: "Quentin Colombet via llvm-dev" <llvm-dev at lists.llvm.org> > To: "vivek pandya" <vivekvpandya at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Nirav Rana" > <h2015087 at pilani.bits-pilani.ac.in>, "Matthias Braun" > <matze at braunis.de> > Sent:

Dear Community, Please find summary of work done during this week as follow: Implementation: ============ During this week we have identified a bug in IPRA due to not considering RegMask of function calls in given machine function. The same bug on AArch64 has been reported by Chad Rosier and more detailed description can be found at https://llvm.org/bugs/show_bug.cgi?id=28144 . To fix this bug

On Mon, Sep 19, 2016 at 6:21 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > I've been looking at this myself for ARM, and came up with a much simpler > solution: lower immediate materializations to a post-RA pseudo and expand > the chain of materialization instructions after register allocation / > remat. Remat only sees one instruction with no

On Saturday, March 4, 2017, Ryan Taylor <ryta1203 at gmail.com> wrote: > Why you can't still expand it through MUL with a Custom lowering? Or am I > missing something? > > Yes we can but problem occurs when we know that it is shift with constant value than if we return ISD::MUL with constant imm operand than LLVM will convert it to SHL again because the constant will be

Is there a compile-time and/or potential runtime cost that makes enableInterleavedAccessVectorization() default to 'false'? I notice that this is set to true for ARM, AArch64, and PPC. In particular, I'm wondering if there's a reason it's not enabled for x86 in relation to PR27881: https://llvm.org/bugs/show_bug.cgi?id=27881 -------------- next part -------------- An HTML

> On May 27, 2016, at 6:55 PM, vivek pandya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Sat, May 28, 2016 at 12:23 AM, vivek pandya <vivekvpandya at gmail.com <mailto:vivekvpandya at gmail.com>> wrote: > > > On Sat, May 28, 2016 at 12:21 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:

static void setXXX(MachineInstr &MI, ...) { for (MachineOperand &MO : MI.operands()) { if (MO.isRegMask()) MO.setRegMask(...); } } > On May 27, 2016, at 7:02 PM, vivek pandya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Sat, May 28, 2016 at 7:29 AM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote: >

Thank you Vivek, I posted an according patch on phabricator. I also took the liberty to change the design a little bit (based on the open projects page http://llvm.org/OpenProjects.html). But take it with a grain of salt, I'm no html expert :) Best regards, Matthias Am Dienstag, 10. Mai 2016 19:48:21 UTC+2 schrieb vivek pandya: > > > > *Vivek Pandya* > > > On Tue, May

On Sat, May 28, 2016 at 7:29 AM, Matthias Braun <matze at braunis.de> wrote: > > On May 27, 2016, at 6:55 PM, vivek pandya via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Sat, May 28, 2016 at 12:23 AM, vivek pandya <vivekvpandya at gmail.com> > wrote: > >> >> >> On Sat, May 28, 2016 at 12:21 AM, Mehdi Amini

Hello Developers, I am working with my other batchmates to improve register remat in LLVM. We want to remat live ranges made of multiple instruction. Just to support our proposal here is a simple example that currently remat does not cover $ cat ~/tmp/tl.c void foo(long); void bar() { for (int i = 0; i < 1600; ++i) foo(3494348345984503943); } $ clang -O3 -S -o - ~/tmp/tl.c -target

On Sat, May 28, 2016 at 12:21 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On May 27, 2016, at 11:49 AM, vivek pandya <vivekvpandya at gmail.com> > wrote: > > > > Hello Mentors, > > > > I have completed writing simple register mask calculator pass, an > immutable pass that stores RegMasks and provides API to query them, and a >

Apologies: didn't notice how old this thread is before replying. On Tue, Mar 22, 2016 at 5:24 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Vivek, > > [+CC Matthias, Quentin] > > Inter-procedural register allocation can be a big win, but my estimate > is that it will be challenging to complete within one summer unless > you're already familiar

Hello Matthias Reisinger, It is simple html page that shows simple abstract ( which I have already added for all projects as per GSoC page) , link to your read-only proposal, blog URL (if you maintain any) , and status reporting interval (if you want to follow) and any other relevant information. You can check out (SVN) related code here http://llvm.org/svn/llvm-project/www/trunk/SummerOfCode/

On Sat, May 28, 2016 at 12:23 AM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > On Sat, May 28, 2016 at 12:21 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> > On May 27, 2016, at 11:49 AM, vivek pandya <vivekvpandya at gmail.com> >> wrote: >> > >> > Hello Mentors, >> > >> > I have