similar to: [RFC] Change DEBUG() macro to LLVM_DEBUG()

+1, claiming the "DEBUG" macro is pretty hostile. Debug.h is included pretty widely from llvm/include/llvm/*, so we can't claim this is some internal macro that users won't see. On Fri, Mar 23, 2018 at 9:18 AM Nicola Zaghen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > We recently stumbled upon some issues with the DEBUG() macro being >

Well, I was hinting at LLVM_DEBUG messages. You can pretty much dump all "actions" Tablegen would take to process a .td file, which should suffice, IMO. On Wed, Aug 5, 2020 at 5:59 PM Paul C. Anagnostopoulos <paul at windfall.com> wrote: > Your reply suggests that there is a way to see debug messages from > TableGen. Is that what you meant? If so, can you explain how that

Sorry Zach, my apologies. I understood now what you mean. I tried and it works!. But now I found that LLVM_DEBUG statements and other output to the console doesn’t show. How do I get that back?. Thanks John > On 4 Nov 2019, at 22:26, Zachary Turner <zturner at roblox.com> wrote: > > You hit Reply on my email but then addressed David. So I want to make sure you saw my

On Monday 07 July 2008 15:36, Chris Lattner wrote: > On Mon, 7 Jul 2008, David Greene wrote: > >>> from our IR to LLVM IR. Those files need to include headers from both > >>> LLVM and our compiler components. That is where the DEBUG conflict > >>> happens. > >> > >> Do you need to use both of the debug mechanisms in the same CPP files?

Some time ago I ran into problems with conflicts because the LLVM DEBUG macro and macros defined by our internal software here. I worked around it but it is ugly. This just came up again today. The fundamental problem is that two pieces of software both use the generic name "DEBUG." This is just problems waiting to happen. We need some kind of namespace. Would the LLVM community

On Jul 8, 2008, at 4:57 AM, Chris Lattner wrote: > On Mon, 7 Jul 2008, David Greene wrote: >>> Since I think it really is a part of the LLVM internals, I don't >>> think >>> that mangling it with a prefix is the right way to go. This would >>> significantly increase verbosity in the code and would be generally >>> detrimental. >>

On Mon, 7 Jul 2008, David Greene wrote: >> Since I think it really is a part of the LLVM internals, I don't think >> that mangling it with a prefix is the right way to go. This would >> significantly increase verbosity in the code and would be generally >> detrimental. > > Verbose, yes, but "generally detrimental?" That's a pretty strong statement.

On Mon, 7 Jul 2008, David Greene wrote: > Some time ago I ran into problems with conflicts because the LLVM DEBUG macro > and macros defined by our internal software here. I worked around it but it > is ugly. > > This just came up again today. The fundamental problem is that two pieces of > software both use the generic name "DEBUG." This is just problems waiting

On Mon, Jan 26, 2009 at 4:45 PM, Dale Johannesen <dalej at apple.com> wrote: > > On Jan 26, 2009, at 4:07 PMPST, Bill Wendling wrote: > >> There is a problem with Objective-C code where a null string is placed >> in the wrong section. If we have this code: >> >> #include <Foundation/Foundation.h> >> void foo() { >> NSLog(@"");

On Monday 07 July 2008 14:18, Chris Lattner wrote: > On Mon, 7 Jul 2008, David Greene wrote: > >> Debug.h should only be #included by .cpp files, not .h files. Are you > >> seeing a case where you need to use both debug macros in a .cpp file? > > > > That's not the issue. We have some interface (.cpp) files that convert > > from our IR to LLVM IR.

Am Mi., 18. März 2020 um 18:15 Uhr schrieb Chawla, Pankaj <pankaj.chawla at intel.com>: > > >> DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another method added to AA that gives additional guarantees. Please see the bug report for details. > > Thanks for updating the bug report but GetUnderlyingObject() doesn't help in this case.

Hello, Bill >> >> I don't see anything obvious wrong, but this is an easy area to >> break. >> I'd recommend running the gcc testsuite and checking for regressions. >> > Okay, that's a good plan. I'm strongly agains any target-specific and language-specific hacks in the generic tree-conversion code. What if we decide to support objc on

Hi Andy, Thanks for the explanations. Yes AMDGPU is in-order and has MicroOpBufferSize = 1. Re "issue limited" and instruction groups: could it make sense to disable the generic scheduler's detection of issue limitation on in-order CPUs, or on CPUs that don't define instruction groups, or some similar condition? Something like: --- a/lib/CodeGen/MachineScheduler.cpp +++

Ok guys, after doing many tutorial arond the web i realize that im not going to learn rails well until a made my own app, so i defined what i want and structured in a way that hope you can understand, maybe we can help each other and define a good starting base(models and relationships) that can be helpful for all of us. Its a little(i think cms), it will consist of basically 4 sections:

I just started messing with puppet, and i love it! I have used cfengine in the past, and were in process of planing to replace cfengine now. One thing thats stumped me this weekend and i know i read your working on virtal defines so i can''t do that, but how can i get arond this issue with the curretn setup. I think i am missing something fundamentally simple here. i have this

As far Am Mi., 18. März 2020 um 11:34 Uhr schrieb Chawla, Pankaj <pankaj.chawla at intel.com>: > >> There seems to be a bug in DI, see Felipe's answer. > Maybe I missed something. There seems to be no resolution to the problem. How can DA fix this without help from alias analysis? DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another

On Mon, 7 Jul 2008, David Greene wrote: >>> from our IR to LLVM IR. Those files need to include headers from both >>> LLVM and our compiler components. That is where the DEBUG conflict >>> happens. >> >> Do you need to use both of the debug mechanisms in the same CPP files? > > In some cases, yes. I have mixed feelings about this. I consider

On Jul 7, 2008, at 5:49 PM, Dominic Hamon wrote: > I completely agree with this point, but then aren't you trading off > one aspect of clarity for another? It is a problem with the C > preprocessor that hits many projects and the equivalent to the > namespace solution for macros is to add a prefix specific to the > project. Ie, use LLVM_DEBUG rather than DEBUG. It hasn't

LLVM Weekly - #221, Mar 26th 2018 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/221>. Welcome to the two hundred and twenty-first issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

Hi I think llvm-dev list (CC'ed) have more visibility in this. On Wed, 22 Apr 2020 at 22:18, milsegv via cfe-dev <cfe-dev at lists.llvm.org> wrote: > Hello everyone, > > It may not be the best place to ask this but I found nothing on the > internet about it. > I'm working on Spectre V1 detection and stumbled upon the mitigation > provided by clang, the