similar to: [LLVMdev] DEBUG

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 Monday 07 July 2008 13:31, Chris Lattner wrote: > 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

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?

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 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.

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 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. >>

Hi all, We recently stumbled upon some issues with the DEBUG() macro being redefined in some internal libraries and some external ones, such as LLVM. After trying out a few ideas to avoid the problem we thought that the simplest solution would be to prefix all generic macro names in order to avoid clashes. A quick search showed that Mesa had a similar issue with DEBUG being used by LLVM and

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

+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 >

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

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

No response yet, so resending. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords ---------- Forwarded message ---------- Date: Fri, 12 Oct 2001 09:44:54 +0300 (EEST) From: Pekka Savola <pekkas at netcore.fi> To: Damien Miller

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.

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 +++

>On Mon, Jun 15, 2009 at 5:49 PM, Gaster, >Benedict<Benedict.Gaster at amd.com> wrote: >> I would like to use the LLVM x86 code generator to emit Intel syntax that >> is >> compatible with Microsoft’s MASM 9.x. Taking the TOT LLVM, from last >> week, I >> have found a number of changes that are required to make this work, most >> of >> which

On Tuesday 16 June 2009 09:48, Aaron Gray wrote: > Appently the GAS Intel backend has flaws and does not work correctly anyway > so the X86IntelAsm backend is designed only to target MASM anyway. gas Intel syntax is indeed broken in LLVM. I'd love to make it work but my work has not (yet) allocated time for that. Maybe I can hack LLVM on the weekends. :) The above discussion leads

Another thing to consider about your feature idea is that the output may be noisy depending on what you were hoping for. SLH tries to mitigate anything that could potentially be a problem and thus it instruments almost every branch, load, and function entry, for example. There isn't a lot of signal about what is really a gadget among the code instrumented by SLH. It really tries to be

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. Those files need to include headers from both LLVM and > our compiler components.

On Jun 16, 2009, at 3:12 PM, David Greene wrote: > On Tuesday 16 June 2009 09:48, Aaron Gray wrote: > >> Appently the GAS Intel backend has flaws and does not work >> correctly anyway >> so the X86IntelAsm backend is designed only to target MASM anyway. > > gas Intel syntax is indeed broken in LLVM. I'd love to make it work > but > my work has not