similar to: [LLVMdev] GSoc 2009 (Bad Subject in the previous email)

Hi Ehsan, All of the projects you have listed are quite interesting. If I were to advocate for one, it would be #2. I think the scope of work is perfect for GSoc. I'd encourage send out a more concrete proposal when you're ready. Thanks, Evan On Mar 27, 2009, at 2:35 PM, Ehsan Amiri wrote: > Dear all > > I am a PhD student of Computer Scince at Simon Fraser University

Hi Evan Thanks for the email. I had a look at gcc implementation of TBAA and I think three main steps in implementation of TBAA for LLVM will be this: April 20 ~ May 23: I will read gcc implementation in depth and play around with LLVM code. May 23 ~ July 6: Implementation and test of a simple version of TBAA that does not work with all aggregate types. I think part of the coding required for

Dear all I am a PhD student of Computer Scince at Simon Fraser University ( http://www.cs.sfu.ca) interested in applying to GSoC. My PhD is focused on theoretical computer science, but since Sep. 2008 I have started working on Software projects again. Currently I am working in COSTAR lab on a high performance regular expression engine based on Parallel bit streams technology. A considerable part

Hi everyone. After lurking for a while, this is my first post to the list. I am working with some graduate students on the general topic of compiler support for SIMD programming and specific projects related to LLVM and my own Parabix technology (parabix.costar.sfu.ca). Right now we have a few course projects on the go and already a question arising out of one of them (SSE2 Hoisting).

Thanks. This is probably one of the patches. So let me rephrase my questions: 1- What is the status of work to support block-local restrict-qualified pointers. 2- Does the set of patches with “llvm.noalias” label, more or less cover this work? Thanks Ehsan From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of 陳韋任 via llvm-dev Sent: Thursday, June 01, 2017 7:57 AM

On Thu, May 26, 2016 at 10:35 AM, Ehsan Amiri via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 7. Wildcard for prefixes - If some statements should be checked > regardless prefix, it should be used //{{*}}, //{{*}}-NEXT, //{{*}}-SAME > and etc. > >> 8. Prefix with regular expressions - If statement should be >> checked if prefix matches some regular

I probably misunderstood the question. You probably want to do this in SelectionDAG. On Fri, Oct 21, 2016 at 10:29 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > You can do this by changing instruction scheduling heuristics. I think the > more important question is if this correct always for all platforms. > > I don't know which scheduler you use. We use

But then I should write // CHECK: something // SSE: something // SSE3: something With this feature it can be write // {{[A-Z0-9]+}} : something From: James Y Knight [mailto:jyknight at google.com] Sent: Thursday, May 26, 2016 5:53 PM To: Ehsan Amiri <ehsanamiri at gmail.com> Cc: Elena Lepilkina <Elena.Lepilkina at synopsys.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject:

Hi Ehsan, In some cases modulo scheduling will insert copy instruction that end up as real copies in the final code. It unavoidable in some cases. For example, let's say a instruction defining a value is scheduled in the first iteration, but one of its uses is scheduled two iterations later. In this case, the kernel needs to create a copy because there will be two values live in the

I have a group of students working with me on some LLVM projects related to our Parabix research. One interesting issue that has come up for us is code generation support for the Haswell new instructions pext and pdep. These instructions shuffle bits within a 64-bit word, either gathering all selected bits to the beginning (pext) or scattering some initial bits throughout (pdep). A natural

Hi Hal, others IIRC, Hal has done some work to support block-local restrict-qualified pointers in LLVM, which was presented in CGO LLVM workshop. I was wondering if all patches for this work are now committed? Is there a way to find the list of patches for this work? Thanks Ehsan -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Mar 22, 2016 at 7:33 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Mar 22, 2016, at 4:15 PM, Ehsan Amiri via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > James, > > I think (1) reduces the number of "do-not-see-through-bitcast" bugs that > we need to uncover and fix between now and the time that typeless pointer > is

7. Wildcard for prefixes - If some statements should be checked regardless prefix, it should be used //{{*}}, //{{*}}-NEXT, //{{*}}-SAME and etc. > 8. Prefix with regular expressions - If statement should be checked > if prefix matches some regular expression, it should be used {{regex}}:, > {{regex}}-NEXT and etc. > > > > I, too, think wildcard and regular

Hello all I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. Best Ehsan Input File: target datalayout =

On Wed, Mar 16, 2016 at 11:00 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > David, > > Could you give us an update on the status of typeless pointer work? How > much work is left and when you think it might be ready? > It's a bit of an onion peel, really - since it will eventually involve generalizing/fixing every optimization that's currently leaning on typed

I overrode getInstrLatency and did some printing to see what is available there. It looks like the registers are still virtual at that point when getInstrLatency is called - is that correct? (we needed to make some decisions based on actual registers that have been assigned since some registers are reserved as address space pointers and we could vary the latency based on which address space

On Tue, Mar 22, 2016 at 1:41 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Sorry I should have been more clear (writing to many email in parallel) > > You're right. I was adding a +1 to you here. > > Especially I wrote "unless there is an acknowledgement that typeless > pointers won't be there before a couple of years" with the PassManager in >

Back to the discussion on the RFC, I still see some advantage in following the proposed solution. I see two paths forward: 1- Change canonical form, possibly lower memcpy to non-integer load and store in InstCombine. Then teach the backends to convert that to integer load and store if that is more profitable. Notice that we are talking about loads that have no use other than store. So it is a

> On Mar 22, 2016, at 4:15 PM, Ehsan Amiri via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > James, > > I think (1) reduces the number of "do-not-see-through-bitcast" bugs that we need to uncover and fix between now and the time that typeless pointer is available. That means it is likely that we have multiple such fixes in the code and then we have to remove

I don't really mind, but the intermediate stage will not be very nice: that a lot of code / tests that needs to be written with bitcast, and all of that while they are deemed to disappear. The added value isn't clear to me considering the added work. I'm not sure it wouldn't add more work for all the cleanup required by the "typeless pointer", but I'm not sure