search for: provable

Hey guys, appreciate the input. Here are some thoughts. ADSI phones are out of the question. This is a business environment, I can't worry about my employees not knowing how to forward calls, answer calls when away from the multiline phone, and no ADSI phone will handle multiple lines that I have found. I would love to put 6 X100P cards in a case and run asterisk on it. but... I

Hey, Are there any plans in applying the changes suggested in "Provably Fixing the SSH Binary Packet Protocol" by Mihir Bellare, Tadayoshi Kohno and Chanathip Namprempre. http://eprint.iacr.org/2002/078/ I guess this would require a new protocol specification and maybe the task of the IETF Secure Shell Working Group. Dries -- Dries Schellekens email: gwyllion at ulyssis.org

On 25 September 2017 at 02:32, Mark D. Baushke <mdb at juniper.net> wrote: > [+CC Loganaden Velvindron <logan at hackers.mu>] primary author of > the RFC 4419 refresh draft. https://datatracker.ietf.org/doc/draft-lvelvindron-curdle-dh-group-exchange/ ? Tangent: has any consideration been given to increasing the maximum allowed beyond 8192 bits (which is below the current NIST

Thanks a lot for the clarification! So if my input .ll is not expected to contain any of the above mentioned weird corner cases, but, after -instcombine, ends up containing "undef" values, then it must be that the input .ll has bugs unknown to me, right? Best Regards, Paul On Wed, Jun 11, 2014 at 3:09 PM, Nick Lewycky <nlewycky at google.com> wrote: > On 11 June 2014 12:26,

How difficult would it be to add a warning to Clang when the programmer performs a cast that provably has no effect? A particular case I have in mind is someone getting confused and calling std::move on an argument to a copy-constructor for a class that doesn't implement move semantics. I would be grateful if someone either (1) told me why this is difficult/impossible, or (2) gave me some

Hi Fellows, If a .ll file contains no "undef"'s, does it necessarily mean that every value is properly initialized before use in the IR? What confuses me is that I notice that -instcombine can introduce "undef" to the previously undef-clean .ll file ... is it always safe to use -instcombine as one of the preprocessing pass? Thanks. Best, Paul -------------- next

Sanjoy, You have changed the subject. We still need real world examples showing how taking advantage of “undef” results in beneficial optimization. My belief is that they don’t exist, my reasoning is this: real world programmers are likely to run UBSan before compiling (or if they don’t they should), therefore it is highly unlikely that any “undef” will actually exist during

Hi, I tried the memory dependency analysis posted by Wojciech on the attached test case. The analysis had to fallback to conservatives answers sometimes, probably (but not sure) due to the existence of several select instructions that might prevent the analysis from correctly find the answer. In this specific test case, these selects are provably useless and I am trying to get rid of them

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

Hi all, I've been thinking about this issue as well, since I'm working with a architecture that can do hardware based loops, but only when the loop count is more than some minimal value. To probably use this, we need some way for the code to specify that a loop variable has a minimum value. > Can't you implement __builtin_assume(cond) to codegen to something like: > >

Anton Vayvod wrote: > Sure, but where these comparisons are needed, for example? RAX and > EAX alias sets intersect and that's enough to decide that these regs > can't be assigned simultaneously. One place these comparisons are used is to build a provably optimal register class tree in a Smith/Ramsey/Holloway allocator. Building it algorithmically is portable to all

Thanks for your insides Sanjoy! I don't really believe that option 2 may work just because even if we recalculate the range for this add recurrency, there are already its derivatives with cached ranges (the most obvious example is sext and expressions where this sext is involved). We can speculate about what is "simple enough" to not cache the ranges, but I believe that there is

The fact two IR values are defined the same way doesn't necessarily imply they are actually the same value. e.g. %a = load volatile i32, i32* %p %b = load volatile i32, i32* %p As Sanjoy said, though, it should always be legal to optimize all uses of different "freeze(%x)" values to use the same def - this is equivalent to choosing the same value for all freezes. It's just not

Under certain circumstances, my compiler outputs basic blocks having the same function: bb_97: ; preds = %bb_1 %476 = getelementptr inbounds %LMtop.I0.ARType, %LMtop.I0.ARType* %0, i64 0, i32 6 %477 = bitcast i8** %476 to %LBstd.Cprocess.CRType** %478 = load %LBstd.Cprocess.CRType*, %LBstd.Cprocess.CRType** %477, align 8 %479 = getelementptr

...ions they already know how to simplify and > fold.  And anything special -- like saturating -- would fall out from > the normal integer operations. I think saturating might warrant intrinsics, but above transform would be one of the optimizations I suggested -instcombine might do if it's provable no saturation can occur. And yes, I'd definitely suggest pattern-matching the pure-integer versions in a backend for a target that supports the fixed-point ones natively if they're more efficient than the expanded versions (i.e. even if saturation isn't needed). It'd also help catc...

On Tue, Jun 19, 2012 at 10:21 PM, Preston Briggs <preston.briggs at gmail.com> wrote: > When compile the following case and look at the SCEV analysis, I notice that > the first two loops don't have a LoopInvariantBackedgeTakenCount > (surprising) and the last one does (not surprising, except in the context of > the first two examples). > > void p4(int *A, int *B, long

Mehdi, I am perusing the 3.8 trunk sources, and don’t find evidence where I would expect it for LLVM “downgrading” a function’s calling convention. PrologEpilogEmitter() { “CodeGen/” ... TFI->determineCalleeSaves() { “Target/XYZ/” TargetFrameLowering::determineCalleeSaves() { “CodeGen/” Return <<< some object derived

On 2008-10-22, at 19:24, Mike Stump wrote: > On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > >> As part of our PHP compiler (phpcompiler.org), it would be great to >> be able to annotate our generated C code with, for example, (var != >> NULL), or (var->type == STRING), and have that information passed >> around (esp interprocedurally at link-time) by the

Hello all, I've been trying to figure out some "questions" related to LLVM IR (not specifically LLVM's, but LLVM's IR does appear to be the best on this planet!) since some time. It'd be great if some one could give some pointers. Given a specific target, and a set of rules that define what is optimal code for that target, can it be proven that the LLVM IR provides the

Hi, I have run into a test case on an out-of-tree target where PBQP fails to complete register allocation after "Attempting to spill already spilled value" (the triggered assert in InlineSpiller::spill(). First, the original LiveInterval is spilled. It is a load of a symbol into a narrow register class, i.e. a subset of the class of address registers. InlineSpiller decides to