search for: iteratee

...le conditional returns on PPC, but the currently documented API for AnalyzeBranch doesn't support it. I propose the following enhancement to the API so that I can teach AnalyzeBranch about conditional return instructions. ---------- Forwarded message ---------- From: Kyle Butt <kyle+llvm at iteratee.net> Date: Tue, May 31, 2016 at 4:07 PM Subject: [PATCH] D20841: TII: Add documentation about conditional exits. NFC To: kyle+llvm at iteratee.net Cc: llvm-commits at lists.llvm.org iteratee created this revision. iteratee added a subscriber: llvm-commits. iteratee set the repository for this...

On Tue, Jan 10, 2017 at 2:31 AM, Peter A Jonsson <pj at sics.se> wrote: > Hi Kyle, > > my apologies for mailing you directly but it seems new user creation is > disabled on the llvm bugzilla. > > We sometime lose edges during IfConversion of diamonds and it’s not > obvious how to reproduce on an upstream target. The documentation for > HasFallThrough says *may*

> On Sep 18, 2017, at 5:17 PM, Kyle Butt <iteratee at google.com> wrote: > > > > On Mon, Sep 18, 2017 at 1:16 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote: > >> On Sep 14, 2017, at 6:53 PM, Kyle Butt via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org...

Hi, I need help debugging a problem a problem that only shows up on PowerPC with one of my commits in the generic CodeGen parts of llvm. I'd apreciate it if someone with access to a PowerPC system could take a look at this: https://reviews.llvm.org/D23097 <https://reviews.llvm.org/D23097> - Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, Dec 14, 2016 at 1:34 PM, James Knight <jyknight at google.com> wrote: > Seems reasonable. > > I'd note additionally that on some architectures, that the success block > *must* be the fallthrough case (that is to say: you must not have any taken > branches between the load-linked and store-conditional) in order to have an > architectural guarantee that two such

On Mon, Sep 18, 2017 at 1:16 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 14, 2017, at 6:53 PM, Kyle Butt via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > I plan on rewriting the block placement algorithm to proceed by traces. > > A trace is a chain of blocks where each block in the chain may fall > through to > the successor in the chain.

I found a bit weird to use address space for this, since the offset of getting stack_guard in TCB is, unfortunately, negative: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610 In my understanding an address space is referring to a segment register (-on powerpc 32bit; or SLB entry on powerpc 64bit?) with a non-negative offset value, so that it's actually accessing

> The semantics around inlining alone are problematic enough to warrant serious hesitation. There are nicer ways to embed CPS call/return into LLVM; I just figured that there would not be much support for adding a new terminator because it would change a lot of code. Ideally we would have a block terminator like: cps call ghccc @bar (.. args ..) returnsto label %retpt Where the