similar to: [LLVMdev] Optimizing Boolean Expression

On Thu, Jun 17, 2010 at 4:30 PM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > Hello > > I compiled the following program using the web interface > > #include <stdio.h> > #include <stdlib.h> > > int main(int argc, char **argv) { >   int a; int b; int c; int d; >   int X = 10; >   a = 777; >   b = a | (atoi(argv[1])); >   c = b |

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

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

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:

I don't know enough about the tradeoff for 1, but 2 seems like a bandaid for something that is not a correctness issue neither 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,

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:

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

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

Hello, I came across the file *omega.cc* which is in directory* xapain-application/omega/* In this file , atoi is used in *Percentage Relevance cutoff *(293 line no) as Percentage lies between 0-100 their is no need to modify atoi . But do we need to check for error's ? Second Implementation is in *collapsing* (301) in which we collapse set of document under a key,range of this key has not

Hello , I came across this function *HtmlParser::decode_entities(string &s)* in *xapian-application/omega/htmlparse.cc* which basically does is extract hex value if any or extract number.For extracting number atoi is used and value returned by it is stored in variable "val" , I think so replacing atoi with strtoul would be useful here as number can have larger value although the

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

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 >

Ok. I have managed to vectorize the second loop in the following code. But the first loop is still not vectorized? Why? int main(int argc, char** argv) { int a[1000], b[1000], c[1000]; int g=0; int aa=atoi(argv[1]), bb=atoi(argv[2]); for (int i=0; i<1000; i++) { a[i]=aa+i, b[i]=bb+i;} for (int i=0; i<1000; i++) { c[i]=a[i] + b[i]; g+=c[i]; } printf("sum: %d\n", g); return 0;

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

Hello, I am working on replacing atoi () and atol() functions with strtol() and strtoul() . I came across many files which uses statement like these time_t secs= atoi(data_span.c_str()), here time_t Datatype is not known but wikipedia says that it is integer so is it necessary to replace atoi with strtol over here ?? And is their any document which helps me what each file function does like

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

lli sum-vec03.ll 5 2 #0 0x0000000000c1f818 (lli+0xc1f818) #1 0x0000000000c1d90e (lli+0xc1d90e) #2 0x0000000000c1da5c (lli+0xc1da5c) #3 0x00007f987c2c3d10 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10d10) #4 0x00007f987c6f0038 #5 0x0000000000989f8c (lli+0x989f8c) #6 0x00000000009383dc (lli+0x9383dc) #7 0x000000000057eedd (lli+0x57eedd) #8 0x00007f987b464a40 __libc_start_main

I feel very strongly that blocking work on making optimization bitcast-ignorant on the typeless pointer work would be a major mistake. Unless we expected the typeless pointer work to be concluded within the near term (say 3-6 months maximum), we should not block any development which would be accepted in the typeless pointer work wasn't planned. In my view, this is one of the largest

But not what David was stating, unless I misread? I was specifically responding to David's wording: "If we're talking about making an optimization able to ignore the bitcast instructions - yes, that work is unnecessary & perhaps questionable given the typeless pointer work. Not outright off limits, but the same time might be better invested in moving typeless pointers