search for: llvm_debug

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

...patches such as https://lists.freedesktop.org/archives/mesa-dev/2016-July/124111.html and https://lists.freedesktop.org/archives/mesa-dev/2016-June/120738.html I noticed that others have left comments in the LLVM source about the same issue, so I decided to try to replace all DEBUG() uses with LLVM_DEBUG() and remove the old macro. A review for the LLVM side of the patch is here: https://reviews.llvm.org/D43624, this was generated mostly by a find/replace regex. This kind of change is quite invasive (~500 files) and might be disruptive to multiple parties. One possible way to avoid some of the...

...s://lists.freedesktop.org/archives/mesa-dev/2016-July/124111.html > and https://lists.freedesktop.org/archives/mesa-dev/2016-June/120738.html > > I noticed that others have left comments in the LLVM source about the > same issue, so I decided to try to replace all DEBUG() uses with > LLVM_DEBUG() and remove the old macro. > A review for the LLVM side of the patch is here: > https://reviews.llvm.org/D43624, this was generated mostly by a > find/replace regex. > > This kind of change is quite invasive (~500 files) and might be > disruptive to multiple parties. One possible...

...internal logic is that the value is always treated as negative if the most significant bit is set. I'm interested in an add or sub that could be using a negative value. I have the following snippet of code to demostrate the issue: APInt Positive(8, 128, false); APInt Negative(8, -128, true); LLVM_DEBUG(dbgs() << "Positive: " << Positive << "\n"); LLVM_DEBUG(dbgs() << "Negative: " << Negative << "\n"); LLVM_DEBUG(dbgs() << "0 + Positive = " << 0 + Positive << "\n"); LLVM_DEBUG(dbgs() &...

...icantly increase verbosity in the code and would be generally > detrimental. Verbose, yes, but "generally detrimental?" That's a pretty strong statement. > As a solution for your problem, would something like this work? > > #include "llvm/Debug.h" > #define LLVM_DEBUG(X) DEBUG(X) > #undef DEBUG > #include "DavidDebug.h" > ... Perhaps. I'll have to think on that. -Dave

...That's a pretty strong >> statement. > > More specifically, this impacts the tyranical :) 80 column limit we > have: > > > DEBUG(cout << "whatever stuff here" << yeah << "ok"); > > is much more clear to me than: > > LLVM_DEBUG(cout << "whatever stuff here" > << yeah << "ok"); > > To be specific, excess wrapping and clutter is what I would find > detrimental. I completely agree with this point, but then aren't you trading off one aspect of clarity f...

...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 be open to changing DEBUG to something like LLVM_DEBUG? I am pushing to have our code be changed in a similar way. It's just not good design to use a generic name like DEBUG that isn't qualified by some prefix/namespace. -Dave

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 suggestion. Let me...

...> Verbose, yes, but "generally detrimental?" That's a pretty strong statement. More specifically, this impacts the tyranical :) 80 column limit we have: DEBUG(cout << "whatever stuff here" << yeah << "ok"); is much more clear to me than: LLVM_DEBUG(cout << "whatever stuff here" << yeah << "ok"); To be specific, excess wrapping and clutter is what I would find detrimental. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...his 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 be open to changing DEBUG to something like > LLVM_DEBUG? I am pushing to have our code be changed in a similar way. 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? -Chris -- http://nondot.org/sabre/ http://llvm.org/

...derlyingObjectsAlias(AA, F->getParent()->getDataLayout(), MemoryLocation::get(Dst), MemoryLocation::get(Src))) { case MayAlias: case PartialAlias: // cannot analyse objects if we don't understand their aliasing. LLVM_DEBUG(dbgs() << "can't analyze may or partial alias\n"); return std::make_unique<Dependence>(Src, Dst); case NoAlias: // If the objects noalias, they are distinct, accesses are independent. LLVM_DEBUG(dbgs() << "no alias\n"); return nullptr; c...

...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. As a solution for your problem, would something like this work? #include "llvm/Debug.h" #define LLVM_DEBUG(X) DEBUG(X) #undef DEBUG #include "DavidDebug.h" ... Or visaversa? -Chris -- http://nondot.org/sabre/ http://llvm.org/

...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 been an issue so far. > At the risk of starting a major thread that has surely been covered > many times before: Is there a reason to still cling to the 80 column > limit and not consider expanding it to a controversial 100 columns? This isn't open f...

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.

...heduler.cpp +++ b/lib/CodeGen/MachineScheduler.cpp @@ -2062,10 +2062,13 @@ getOtherResourceCount(unsigned &OtherCritIdx) { if (!SchedModel->hasInstrSchedModel()) return 0; - unsigned OtherCritCount = Rem->RemIssueCount - + (RetiredMOps * SchedModel->getMicroOpFactor()); - LLVM_DEBUG(dbgs() << " " << Available.getName() << " + Remain MOps: " - << OtherCritCount / SchedModel->getMicroOpFactor() << '\n'); + unsigned OtherCritCount = 0; + if (some condition) { + OtherCritCount = Rem->RemIssueC...

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

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

...StackColoring::runOnMachineFunction(MachineFunction &Func) { ... ... remapInstructions(SlotRemap); + bool markerCount = removeAllMarkers(); + DenseMap<int, int>::iterator itr = SlotRemap.begin(); + const AllocaInst *dInst = MFI->getObjectAllocation(itr->first); + LLVM_DEBUG(dbgs() << "Set break point here to inspect dInst\n"); + return markerCount; } I'm using the following test-case to reproduce the issue: *testcase.cpp* class d { float b[4]; }; d operator-(d); struct e { struct f { int *c[4]; }; void h(const d &); }; stru...

...inal C++ source code, so I can't give you advice on implementing > that in LLVM. Hopefully someone else can chime in who understands the LLVM > stack better than me. > > > *If you'd like to get a better understanding of how SLH works:* > > Have you looked into using the LLVM_DEBUG macro? You can use it to print > where you want from the SLH pass. > Check it out here: > https://llvm.org/docs/ProgrammersManual.html#the-llvm-debug-macro-and-debug-option You'll > have to add it where you want to see what SLH is doing in the > X86SpeculativeLoadHardening.cpp fi...

...day. 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 be open to changing DEBUG to something like > > LLVM_DEBUG? I am pushing to have our code be changed in a similar way. > > 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...