search for: ehsanamiri

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 GenericScheduler and > PostGenericScheduler before and aft...

...s 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 To: ehsanamiri at gmail.com Cc: llvm-dev Subject: Re: [llvm-dev] restrict pointer support in LLVM 4.0 Googling shows https://reviews.llvm.org/D9403, I think that's pretty close what you're looking at? 2017-06-01 2:10 GMT+08:00 Ehsan Amiri via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at...

...fies "bandaid patches" while there is > a clear path forward, i.e. typeless pointers, unless there is an > acknowledgement that typeless pointers won't be there before a couple > of years. > > -- > Mehdi > >> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri <ehsanamiri at gmail.com >> <mailto:ehsanamiri at gmail.com>> wrote: >> >> 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-in...

...a regression. I'm not sure it justifies "bandaid patches" while there is a clear path forward, i.e. typeless pointers, unless there is an acknowledgement that typeless pointers won't be there before a couple of years. -- Mehdi > On Mar 22, 2016, at 11:32 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > > 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 t...

...path forward, i.e. typeless pointers, unless there is an acknowledgement that typeless pointers won't be there before a couple of years. >>>> >>>> -- >>>> Mehdi >>>> >>>>> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri < <mailto:ehsanamiri at gmail.com>ehsanamiri at gmail.com <mailto:ehsanamiri at gmail.com>> wrote: >>>>> >>>>> Back to the discussion on the RFC, I still see some advantage in following the proposed solution. I see two paths forward: >>>>> >>>>>...

..."bandaid patches" while there is a clear path forward, i.e. typeless pointers, unless there is an acknowledgement that typeless pointers won't be there before a couple of years. >> >> -- >> Mehdi >> >>> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri <ehsanamiri at gmail.com <mailto:ehsanamiri at gmail.com>> wrote: >>> >>> 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-inte...

...less there is an acknowledgement that typeless pointers won't be there before a couple of years. >>>>>> >>>>>> -- >>>>>> Mehdi >>>>>> >>>>>>> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri < <mailto:ehsanamiri at gmail.com>ehsanamiri at gmail.com <mailto:ehsanamiri at gmail.com>> wrote: >>>>>>> >>>>>>> Back to the discussion on the RFC, I still see some advantage in following the proposed solution. I see two paths forward: >>>>>>&gt...

..., i.e. typeless pointers, unless >>> there is an acknowledgement that typeless pointers won't be >>> there before a couple of years. >>> >>> -- >>> Mehdi >>> >>>> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri <ehsanamiri at gmail.com >>>> <mailto:ehsanamiri at gmail.com>> wrote: >>>> >>>> Back to the discussion on the RFC, I still see some advantage >>>> in following the proposed solution. I see two paths forward: >>>> >>>>...

...sed 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 pointer register is being used - but it looks like they're virtual there) Phil On Mon, Jun 6, 2016 at 3:10 PM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > Hi Phil > > There are some comments in "include/llvm/Target/TargetItinerary.td" where > class InstrItinData is defined. > > B is the number of cycles after issue where the first operand of the > instruction is defined. A is the number of cy...

...that typeless >>>>> pointers won't be there before a couple of years. >>>>> >>>>> -- >>>>> Mehdi >>>>> >>>>>> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri >>>>>> <ehsanamiri at gmail.com> wrote: >>>>>> >>>>>> Back to the discussion on the RFC, I still see some advantage >>>>>> in following the proposed solution. I see two paths forward: >>>>>> >>>>>> 1- Change canon...

...atches" while there is a clear path forward, >> i.e. typeless pointers, unless there is an acknowledgement that typeless >> pointers won't be there before a couple of years. >> >> -- >> Mehdi >> >> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri < <ehsanamiri at gmail.com> >> ehsanamiri at gmail.com> wrote: >> >> 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 an...

...sure it justifies "bandaid patches" while there is a clear path forward, > i.e. typeless pointers, unless there is an acknowledgement that typeless > pointers won't be there before a couple of years. > > -- > Mehdi > > On Mar 22, 2016, at 11:32 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > > 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 c...

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: Re: [llvm-dev] RFC: FileCheck Enhancements On Thu, May 26, 2016 at 10:35 AM, Ehsan Amiri via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm...

...gt; an > > > acknowledgement that typeless pointers won't be there before a > > > couple of years. > > > > > > -- > > > > > > Mehdi > > > > > > > On Mar 22, 2016, at 11:32 AM, Ehsan Amiri < > > > > ehsanamiri at gmail.com > > > > > > > > > wrote: > > > > > > > > > > Back to the discussion on the RFC, I still see some advantage > > > > in > > > > following the proposed solution. I see two paths forward: > > > &...

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

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

...a clear path forward, >>> i.e. typeless pointers, unless there is an acknowledgement that typeless >>> pointers won't be there before a couple of years. >>> >>> -- >>> Mehdi >>> >>> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri < <ehsanamiri at gmail.com> >>> ehsanamiri at gmail.com> wrote: >>> >>> 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 memcp...

...hing to do. But there might be other reasons for the current canonical form that I am not aware of. Please let me know what you think. Thanks Ehsan On Wed, Mar 16, 2016 at 2:13 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > 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...

...ple of years. >>>>>>> >>>>>>> -- >>>>>>> Mehdi >>>>>>> >>>>>>>> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri >>>>>>>> <ehsanamiri at gmail.com >>>>>>>> <mailto:ehsanamiri at gmail.com>> wrote: >>>>>>>> >>>>>>>> Back to the discussion on the RFC, I still see some >>>>>>>> advantage in fol...

...t;> >>>>>>>> -- >>>>>>>> Mehdi >>>>>>>> >>>>>>>>> On Mar 22, 2016, at 11:32 AM, Ehsan Amiri >>>>>>>>> <ehsanamiri at gmail.com >>>>>>>>> <mailto:ehsanamiri at gmail.com>> wrote: >>>>>>>>> >>>>>>>>> Back to the discussion on the RFC, I still see >>>>>>>>>...