search for: llvm_fallthrough

I came across a weird-looking use of LLVM_FALLTHROUGH which I think is completely spurious, but I figured I should check with the group mind before ripping it out. Basically, if you have multiple cases with no code in between, you do *not* need LLVM_FALLTHROUGH, right? switch (Foo) { case Bar1: LLVM_FALLTHROUGH; // not needed case Bar2:...

Hi llvmdev, llvm-commits, There was a discussion on this topic a while ago, and now I've decided to make a formal proposal and post it here. I propose to add the LLVM_FALLTHROUGH macro for specifying intended fall-through locations between switch cases. *INTRODUCTION* The switch construct of C/C++ languages allows fall-throughs between switch labels when control flow is not directed elsewhere by a break, return or continue statement or other ways. There are certain coding...

...icit-fallthrough* diagnostic is already implemented, and the patch in this thread is a portability macro for *[[clang::fallthrough]]*attribute (which is also implemented, of course). I only need an approval from community to add this macro and replace comment-only fall-through annotations with the *LLVM_FALLTHROUGH;* macro. > -Cameron > > On Thu, Jul 26, 2012 at 2:17 PM, Alexander Kornienko <alexfh at google.com>wrote: > >> Is anyone interested in introducing fall-through annotations and the >> related diagnostic in LLVM/Clang code? >> >> >> On Mon, Jul 2, 201...

...at 9:59 AM, Alexander Kornienko wrote: > Hi llvmdev, llvm-commits, > > There was a discussion on this topic a while ago, and now I've decided to make a formal proposal and post it here. I missed the earlier discussion, so I'm sorry for chiming in late. > I propose to add the LLVM_FALLTHROUGH macro for specifying intended fall-through locations between switch cases. I don't really see that the tradeoff here is worthwhile. It is possible that we have some fallthrough bugs, but the cost of sprinkling this macro everywhere doesn't seem like the right tradeoff. -Chris

...e: > >> Hi llvmdev, llvm-commits, >> >> There was a discussion on this topic a while ago, and now I've decided to make a formal proposal and post it here. > > I missed the earlier discussion, so I'm sorry for chiming in late. > >> I propose to add the LLVM_FALLTHROUGH macro for specifying intended fall-through locations between switch cases. > > I don't really see that the tradeoff here is worthwhile. It is possible that we have some fallthrough bugs, but the cost of sprinkling this macro everywhere doesn't seem like the right tradeoff. > W...

...vm-commits, > >> > >> There was a discussion on this topic a while ago, and now I've decided > to make a formal proposal and post it here. > > > > I missed the earlier discussion, so I'm sorry for chiming in late. > > > >> I propose to add the LLVM_FALLTHROUGH macro for specifying intended > fall-through locations between switch cases. > > > > I don't really see that the tradeoff here is worthwhile. It is possible > that we have some fallthrough bugs, but the cost of sprinkling this macro > everywhere doesn't seem like the r...

...v, llvm-commits, > >> > >> There was a discussion on this topic a while ago, and now I've decided to make a formal proposal and post it here. > > > > I missed the earlier discussion, so I'm sorry for chiming in late. > > > >> I propose to add the LLVM_FALLTHROUGH macro for specifying intended fall-through locations between switch cases. > > > > I don't really see that the tradeoff here is worthwhile. It is possible that we have some fallthrough bugs, but the cost of sprinkling this macro everywhere doesn't seem like the right tradeoff....

Great! Thanks everyone for the input, I'm going to start splitting up the patch. I'll send out the non-mechanical parts separately. On Wed, Oct 31, 2018 at 10:03 PM Chris Lattner <sabre at nondot.org> wrote: > On Oct 31, 2018, at 2:24 PM, Reid Kleckner <rnk at google.com> wrote: > > Alex Kornienko proposed enabling this warning back in 2012 here: >

...on on this topic a while ago, and now I've >>>> decided to make a formal proposal and post it here. >>>> > >>>> > I missed the earlier discussion, so I'm sorry for chiming in late. >>>> > >>>> >> I propose to add the LLVM_FALLTHROUGH macro for specifying intended >>>> fall-through locations between switch cases. >>>> > >>>> > I don't really see that the tradeoff here is worthwhile. It is >>>> possible that we have some fallthrough bugs, but the cost of sprinkling >&g...

...; >> >> There was a discussion on this topic a while ago, and now I've decided >> to make a formal proposal and post it here. >> > >> > I missed the earlier discussion, so I'm sorry for chiming in late. >> > >> >> I propose to add the LLVM_FALLTHROUGH macro for specifying intended >> fall-through locations between switch cases. >> > >> > I don't really see that the tradeoff here is worthwhile. It is >> possible that we have some fallthrough bugs, but the cost of sprinkling >> this macro everywhere doesn...

...There was a discussion on this topic a while ago, and now I've >>> decided to make a formal proposal and post it here. >>> > >>> > I missed the earlier discussion, so I'm sorry for chiming in late. >>> > >>> >> I propose to add the LLVM_FALLTHROUGH macro for specifying intended >>> fall-through locations between switch cases. >>> > >>> > I don't really see that the tradeoff here is worthwhile. It is >>> possible that we have some fallthrough bugs, but the cost of sprinkling >>> this macr...

I'll save you a review iteration. This is updated to match llvm coding style. Capital camel case variable names and uses LLVM_FALLTHROUGH instead of the comment. static bool printAsmMRegister(X86AsmPrinter &P, const MachineOperand &MO, char Mode, raw_ostream &O) { unsigned Reg = MO.getReg(); + bool EmitPercent = true; + switch (Mode) { default: return true; // Unknown mode. c...

On Wed, 2018-02-07 at 23:30 +0000, Chandler Carruth wrote: > This should go to llvm-commits as a proper review. Do you want to do > that David? Want someone on our end to pick it up? I'll attempt to add some test cases... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available

On Wed, 2018-02-07 at 15:47 -0800, Craig Topper wrote: > I'll save you a review iteration. This is updated to match llvm > coding style. Capital camel case variable names and uses > LLVM_FALLTHROUGH instead of the comment. Thanks. How's this for a test? ; RUN: llc < %s -mtriple=i686-- -no-integrated-as | FileCheck -check-prefix=X86 %s ; RUN: llc < %s -mtriple=x86_64-- -no-integrated-as | FileCheck -check-prefix=X64 %s ; If the target does not have 64-bit integer registers, emit 32...

> On Jan 23, 2017, at 12:36, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/23/2017 5:21 AM, Jonas Paulsson wrote: >> Hi Eli, >> >> I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? >> >> My understanding is that returning SDValue()

...n Wed, Feb 7, 2018 at 4:07 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Wed, 2018-02-07 at 15:47 -0800, Craig Topper wrote: > > I'll save you a review iteration. This is updated to match llvm > > coding style. Capital camel case variable names and uses > > LLVM_FALLTHROUGH instead of the comment. > > Thanks. How's this for a test? > > ; RUN: llc < %s -mtriple=i686-- -no-integrated-as | FileCheck > -check-prefix=X86 %s > ; RUN: llc < %s -mtriple=x86_64-- -no-integrated-as | FileCheck > -check-prefix=X64 %s > > ; If the target does...