similar to: [LLVMdev] Vector logic regression in r73431

On Wed, Jul 29, 2009 at 3:45 AM, Nicolas Capens<nicolas at capens.net> wrote: > So could anyone who knows the ins and outs of this code have a look at how > to make it handle vectors correctly? Or if that’s not an option right now, > please revert the broken optimizations. Note that there might be more things > affected than visitAnd, visitOr and vistXor, I’ve only been able to

Hi all, Hi Eli, No, that appears to be something unrelated. I'm currently using revision 75246, while that patch only seems to apply to some later revision. Anyway, I actually located the real bug. Right at the end of InstCombiner::SimplifyDemandedUseBits, there's this piece of code: // If the client is only demanding bits that we know, return the known // constant. if

On Thu, Jul 30, 2009 at 5:57 AM, Nicolas Capens<nicolas at capens.net> wrote: > No, that appears to be something unrelated. I'm currently using revision > 75246, while that patch only seems to apply to some later revision. I don't see the connection... anyway, I can't easily help you with an old revision. > Anyway, I actually located the real bug. Right at the end of

Hi! I've attached a patch which takes care of the issues mentioned (and adds two tests). -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ripple-bucket.diff Type: text/x-diff Size: 3318 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/0814e3e8/attachment.diff>

Hi all! I've been tinkering with LLVM's code-base for a few days, hoping to start on one of the ideas mentioned in the "Open Projects" page (I was told 'Improving the current system'/'Miscellaneous Improvements'/5 would be a good start). While I was at it, I also took a stab at finishing up one of the TODOs. I've attached the patch for review. --

Hi As I understand live variable analysis will set the def/kill properties of operands. In that case, is it still needed to set the kill flags when possible during lowering? thanks dz

/Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/ InstructionCombining.cpp: In member function ‘llvm::Instruction*<unnamed>::InstCombiner::visitAnd (llvm::BinaryOperator&)’: /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/ InstructionCombining.cpp:3597: warning: ‘RHSCC’ may be used uninitialized in this function /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/

I'm new to LLVM dev, but I have been working with a target with a minimum addressable byte of 16-bits. I found that in DAGCombiner::visitAND, EVT::isRound could create i8 loads on my 16-bit target which are ultimately invalid. EVT::isRound appears to use a hard-coded 8, rather than pulling the targets BitsPerByte field. Is this a potential bug or is there a better way to address this? Hard

On Tue, Mar 8, 2011 at 6:19 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi! > > I've attached a patch which takes care of the issues mentioned (and adds two > tests). > Index: test/Transforms/InstCombine/sext.ll > =================================================================== > --- test/Transforms/InstCombine/sext.ll (revision 127153) > +++

On Sun, Mar 6, 2011 at 10:11 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > While I was at it, I also took a stab at finishing up one of the TODOs. I've > attached the patch for review. Comments inline. For those of you following at home, this code is in InstCombiner::WillNotOverflowSignedAdd(), and the first line of the initial comment is: // If one of the

No...maybe i don't explain u well. After that B call C andC not answer (go in timeout), B hear first the beeperr and then, together A the busy tone. Now i can't re-take the call :| Thanks Giordano -----Messaggio originale----- Da: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] Per conto di Gavin Hamill Inviato: mercoled? 1 giugno 2005 12.34 A:

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)

Hi Sam, On 09/07/13 17:01, Sam Cristall wrote: > I'm new to LLVM dev, but I have been working with a target with a > minimum addressable byte of 16-bits. I found that in > DAGCombiner::visitAND, EVT::isRound could create i8 loads on my 16-bit > target which are ultimately invalid. EVT::isRound appears to use a > hard-coded 8, rather than pulling the targets BitsPerByte field.

Hi, Thanks for yuor answer. The boot time of the phone is very very fast, 10 sec to startup and 2 or 3 second to login to asterisk. I set the NTP server to 255.255.255.255 so it don't try to get time. I thinked carefully to your scenario and i am going to try it, but i don't known if it could like to my customer I will try also to use CVS, but i am skeptic to utilize asterisk to

> On Mar 17, 2017, at 6:12 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls being the

> On Mar 17, 2017, at 6:12 PM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls

In my testing results are not that impressive, but that's because I'm now focusing on Os. For me even complete disabling of all KnownBits-related patterns in InstCombine places the results very close to the noise level. In my original patch I also had some extra patterns moved under ExpensiveCombines - and that seems to make a difference too (without this part, or without the KnownBits

> To (hopefully) make it easier to answer this question, I've posted my (work-in-progress) patch which adds a known-bits cache to InstCombine. > I rebased it yesterday, so it should be fairly easy to apply: https://reviews.llvm.org/D31239 - Seeing what this does to the performance of the > benchmarks mentioned in this thread (among others) would certainly be interesting. Thanks! I

On 03/17/2017 04:30 PM, Mehdi Amini via llvm-dev wrote: > >> On Mar 17, 2017, at 11:50 AM, Mikhail Zolotukhin via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> One of the most time-consuming passes in LLVM middle-end is >> InstCombine (see e.g. [1]). It is a very powerful pass capable

I've had this a long time but haven't submitted it yet. I've tried to mirror the ia32 setup, so there should be a new subdirectory src/libFLAC/ppc . The first two attachments go there. The third is a context diff for src/libFLAC/Makefile.am . I have some more modified files, which I figured I'd submit after the above are checked in and working for somebody other than me. If you