similar to: LLVM Stable

I've gone ahead and updated both stable and testing for the branch. Sorry that it hasn't been updated in a while - I'll make sure it happens more regularly now. Thanks! -eric On Tue, Nov 22, 2016 at 8:25 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think the process has bitrotted a bit and not sure it's going to > continue to be updated

Dear List, As someone who is in the process of trying to migrate from Excel, I'd appreciate any help on this question: I have a data set and want to fit, say, three distributions to it. I would like to create a plot that shows my data points against all three fitted curves (estimated d.f.). Basically, I lookint to creat a plot that looks like the one presented in the attached paper (Figure

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>

Hello, I assumed SCEV purpose was to be 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

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-of-bounds mapping won't generally be one of the allowed

Hello, Yes? Where is allActive defined, I couldn't find it. Basically, a BB is control divergent if it's execution depends on a branch that itself depends on a divergent ssa value. On Fri, Jul 21, 2017 at 4:13 PM, Zaks, Ayal <ayal.zaks at intel.com> wrote: > What would be the definition of “isControlDivergent(BasicBlock*)”; the > complementary of “allActive(BasicBlock*)” –

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 And got: ... -- Performing Test

On Wed, Jul 5, 2017 at 3:59 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 07/04/2017 01:41 AM, Dr.-Ing. Christoph Cullmann via llvm-dev wrote: > >> Hi, >> >> Hi Alexandre, >>> >>> LLVM currently doesn't have trunc nsw/nuw, no. >>> Which frontend would emit such instructions? Any application in mind?

Hi, Even if there are no ways in which a *frontend* can produce nsw truncs, it may still be useful to have if optimization passes can usefully attach nsw to truncates (after proving the truncates don't "overflow"). For instance in %a = ashr i64 %v, i32 33 %t = trunc %a to i32 the trunc can be marked nsw. However, the burden of proof here is to show that we can do some useful

According to 6.3.1.3/3 of the C standard (I didn't check C++): "3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised." I *think* that means that IF a signal is raised then the signal raised could be one that you can't guarantee to be able to return from

Note that there is a slight difficulty due to the fact that we "sink" the trunc: (zext i16 {0,+,1}<%bb> to i32) + (65536 * ({0,+,1}<nuw><%bb> /u 65536) Here the recurrence lost it's <nuw> and got reduced to a i16 (on the left), but not on the right. But we can prove: - that (zext i16 {0,+,1}<%bb> to i32) has the same 16 LSB than (i32

Ok. 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. >

I did not observe any assertion. In addition, the documentation ( https://llvm.org/docs/LangRef.html#undefined-values) says: The string ‘undef’ can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. Undefined values may be of any type (other than ‘label’ or ‘ void’) and be used anywhere a constant is permitted. Either way,

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

Yes, it's still respected in this case, as the only instructions that will be deleted have been RAUW with undef. Originally, all instructions where RAUW but only non-EHPad were deleted (that means EHPad were RAUW but not deleted). Then it was later patched by not RAUW token instructions and now not deleting EHPad nor token instructions. My assumption is that the instructions we wanted to

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 times always give the value of its

Hello, I was thinking about printing SCEV into DiagnosticInfo messages, an example would be to print the loop trip count of loops, or the stride of memory accesses. I ran into two problems: - DiagnosticInfo is in Core, SCEV is in Analysis, so it is a little bit weird (I declare the operator<< overload for SCEV* in DiagnosticInfo, but only define it in ScalarEvolution) - I would like to

Hello, I noticed that our SCEVUDiv does not simplify anything when the RHS is not a constant. Is that because there is a potential issue 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

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

Hello, Our llvm::iterator_range is quite minimalist in design, it does not even have an "empty" method. Is that because we want it to work on 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