search for: isoard

And again... LLVM_BUILD_LLVM_DYLIB:BOOL=ON LLVM_LINK_LLVM_DYLIB:BOOL=ON This one is the good one... maybe. On Tue, Sep 6, 2016 at 11:35 PM, Alexandre Isoard < alexandre.isoard at gmail.com> wrote: > That is because I mistyped it: > LLVM_ENABLE_LLVM_DYLIB:BOOL=ON > LLVM_LINK_LLVM_DYLIB:BOOL=ON > > On Tue, Sep 6, 2016 at 11:31 PM, Wink Saville <wink at saville.com> wrote: > >> On Tue, Sep 6, 2016 at 3:05 PM, Alexandre...

On 07/05/2017 03:10 PM, Alexandre Isoard wrote: > Ah, ok. I read it wrong. In *neither* case it is UB. > > Hum, can an implementation define it as UB? :-) Nope :-) The only case I've thought of where we could add these for C++ would be on conversions to (most) enums (because they used signed underlying types and the out-o...

...omplementary of “allActive(BasicBlock*)” – blocks known to execute all > lanes, whenever reached? Note the (distinct) term “rewire targets” that > Ralf Karrenberg used in his thesis. > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Alexandre > Isoard via llvm-dev > *Sent:* Friday, July 14, 2017 20:53 > *To:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* [llvm-dev] [SPIR/PTX] Divergence analysis for BasicBlocks > > > > Hello, > > > > It seems to me that our current DivergenceAnalysis does not save whic...

On Tue, Sep 6, 2016 at 3:05 PM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > LLVM_ENABLE_DYLIB Where/when/how do you specify LLVM_ENABLE_DYLIB and LLVM_LINK_DYLIB? I tried the following on the cmake command line: $ cmake -G Ninja .. -DCMAKE_INSTALL_PREFIX=/home/wink/opt/llvm -DLLVM_ENABLE_DYLIB=true -DLLVM_LINK_DYLIB=true...

...a normal form, but then I wondered which one of those is the normal form: (zext i16 (trunc i32 %a to i16) to i32) vs (-((%a /u 65536) *u 65536) + %a) The first one is nice for interval analysis, and known bit analysis. The second one is nice when plugged into gep of 2d arrays. -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170725/7652532d/attachment.html>

...t; /u 65536) has the same 16 MSB than (i32 {0,+,1}<nuw><%bb>) And therefore conclude that we can simplify it to (i32 {0,+,1}<nuw><%bb>). The difficulty is to come up with the (i32 {0,+,1}<nuw><%bb>) in the first place. On Fri, Aug 11, 2017 at 5:57 PM, Alexandre Isoard < alexandre.isoard at gmail.com> wrote: > Hello again, > > On that subject, I have the following SCEV: > > (zext i16 (trunc i32 %a to i16) to i32) + ((%a /u 65536) *u 65536) > > That I would like to normalize into: > > %a > > I am not sure where is the most n...

...truncate by taking the remainder modulus the number of values that can be represented in the destination type, but that might not be a power of two. I would guess there is very little code in the wild that conforms to a strict interpretation of all this. On Thu, Jul 6, 2017 at 5:24 PM, Alexandre Isoard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Hal, > > I just want to check I understand correctly the subtlety, in C++ an > overflowing signed addition is an undefined behavior (so Clang adds the nsw > keyword to the sign add), while a signed cast that overflow is &q...

...modulus the > number of values that can be represented in the destination type, but that > might not be a power of two. > > I would guess there is very little code in the wild that conforms to a > strict interpretation of all this. > > On Thu, Jul 6, 2017 at 5:24 PM, Alexandre Isoard via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi Hal, >> >> I just want to check I understand correctly the subtlety, in C++ an >> overflowing signed addition is an undefined behavior (so Clang adds the nsw >> keyword to the sign add), while a...

...vior? - if the conversion for signed types is UB, then this is a direct application of those flags, isn't it? -Hal > > > >> Greetings >> Christoph >> >> Thanks, >>> Nuno >>> >>> -----Original Message----- >>> From: Alexandre Isoard via llvm-dev >>> Sent: Monday, July 3, 2017 8:38 PM >>> To: llvm-dev >>> Subject: [llvm-dev] trunc nsw/nuw? >>> >>> >>> Hello, >>> >>> From [1], trunc does not seems to have a nsw/nuw attribute. >>> Is it possible to...

...HPad we > can’t erase: unwind edges are required to have an EHPad instruction, so > erasing them requires modifying the block’s predecessors. We don’t need to > keep an intrinsic call with no uses that produces a token result. > > > > -Eli > > > > *From:* Alexandre Isoard <alexandre.isoard at gmail.com> > *Sent:* Tuesday, June 16, 2020 10:25 PM > *To:* Eli Friedman <efriedma at quicinc.com> > *Cc:* David Majnemer <david.majnemer at gmail.com>; llvm-dev at lists.llvm.org > *Subject:* [EXT] Re: [llvm-dev] InstCombine doesn't delete in...

...To go back to the original issue, would it be meaningful to add a SCEVUMax(0, BTC) on the final BTC computed by SCEV? So that it does not use "negative values"? On Wed, Aug 15, 2018 at 2:40 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. > > But on this example: > > define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { >> entry: >> %adds = add nsw i32 %x, %y >> %addu = add nuw i32 %x, %y >> %cond = select i1 %b, i3...

On Wed, Aug 24, 2016 at 10:11 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 24 August 2016 at 08:48, Alexandre Isoard via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I am probably stating the obvious, but if the function is side-effect > free > > (onlyReadsMemory) it is valid to remove it. > > > > But I am guessing that does not belong to this pass. > > I think it d...

...in dead code; > even if we know the instruction is dead, it could still have uses in other > dead code. If an instruction still has uses, we can’t erase it. > > > > -Eli > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Alexandre > Isoard via llvm-dev > *Sent:* Tuesday, June 16, 2020 7:33 PM > *To:* David Majnemer <david.majnemer at gmail.com>; llvm-dev < > llvm-dev at lists.llvm.org> > *Subject:* [EXT] [llvm-dev] InstCombine doesn't delete instructions with > token > > > > Hello David, &gt...

Hi Alexandre, On Wed, Oct 19, 2016 at 11:19 AM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > I am probably missing something important, but what I mean is that you can > always convert: > > %y = xor %x, %x > to > %y = 0 > > Regardless of if %x is/might be an undef. That is, consider that reading %x > any number of ti...

On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: > > Hello, > > I am not sure about the semantic (if any) of returns_twice and noreturn > attributes. > > int fork() __attribute__((returns_twice)); > void join(int) __attribute__((noreturn)); > > int f(int n) { > int t = fork(); > n++; &gt...

...> %cond U: full-set S: full-set > Determining loop execution counts for: @func Would there be problems if we properly considered nuw/nsw flags when unifying SCEVs? On Wed, Aug 15, 2018 at 1:59 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 1:31 PM, Alexandre Isoard wrote: > > Is that why we do not deduce +<nsw> from "add nsw" either? > > > Essentially, yes. > > Is that an intrinsic limitation of creating a context-invariant > expressions from a Value* or is that a limitation of our implementation > (our unification n...

...ittle bit weird (I declare the operator<< overload for SCEV* in DiagnosticInfo, but only define it in ScalarEvolution) - I would like to print meaningful expressions that does not involve llvm-ir variables. I think the second problem is hard, how would you suggest to proceed? -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180604/f68fc403/attachment.html>

...e with division by zero being simplified? For instance, would it be okay to simplify: ((%i * %n)<nuw> /u %n) into: %i The way I see it, if %n is 0, then that division is undefined and we can "define it", at will, as being %i. Would that make sense in SCEV world? -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180802/999eddf4/attachment.html>

...all iterators (including those dirty OutputIterator)? Maybe we can add a little bit to it? I recently needed: - bool empty() - value_type& font() - value_type& back() - void advance_begin(difference_type n) - void advance_end(difference_type n) Would you be open to those? -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171211/962ff1d2/attachment.html>

...e first, second one second) - point to instructions in different basic block (the BB of the first dominate the BB of the second, and the BB of the second post-dominate the BB of the first) I'm not sure if I can trick InstIterator into doing that for me (with a custom BB type?). -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180409/375a02b6/attachment.html>