search for: detriment

...d at this > sort of thing. Yes, I understand your feelings here. > 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. > 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&qu...

> So, clearly the optimization is making things worse. Would it be okay to delete > this code and eliminate the isBaseAddressKnownZero? I would like to get rid of > it. I think it is OK. I can see ld/gdb expecting a relocation, but if that is the case we should just have a flag saying it is needed. If you are really motivated to check it, run the gdb testsuite with your patch, but on

----- Original Message ---- > From: Rafael Ávila de Espíndola <rafael.espindola at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Thu, March 10, 2011 4:22:32 PM > Subject: Re: [LLVMdev] Detrimental optimization for reducing relocations. > > > So, clearly the optimization is making things worse. Would it be okay to >delete > > this code and eliminate the isBaseAddressKnownZero? I would like to get rid >of > > it. > > I think it is OK. I can see ld/gdb e...

> Will the testsuite work on ELF? The patch does not make any functional change > for the other formats. I know that gdb is okay with the example, but that > doesn't say very much. The patch is probably OK then. The gdb testsuite works with clang on ELF. There used to be a lot of silly failures like it not expecting clang warnings, but I think most of the current ones are real.

> From: Rafael Ávila de Espíndola <rafael.espindola at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Thu, March 10, 2011 4:22:32 PM > Subject: Re: [LLVMdev] Detrimental optimization for reducing relocations. > > > So, clearly the optimization is making things worse. Would it be okay to >delete > > this code and eliminate the isBaseAddressKnownZero? I would like to get rid >of > > it. > > I think it is OK. I can see ld/gdb e...

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. More specifically, this impacts the tyranical :) 80 column limit we have: DEBUG(cout << "whatever stuff here" << yeah << "ok"); is much more clear to me...

I was looking into the AsmPrinter and the method EmitSectionOffset which contains this code: -------------------------------------------------------------------------------- // If the section in question will end up with an address of 0 anyway, we can // just emit an absolute reference to save a relocation. if (Section.isBaseAddressKnownZero()) { OutStreamer.EmitSymbolValue(Label, 4,

...tem as possible requires interoperability with the tools used to compile those libraries. In this case it is MSVC and their ABI. > Sorry if I sound dismissive but it's quite irritating to see how > authoritativeness is attributed to something that doesn't deserve it > *to* *the* *detriment* *of* *our* *own* *project*. > How can having an MSVC compatible compiler be to the detriment of clang and llvm? No one is trying to break mingw here, merely add support for something else. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.l...

> How can having an MSVC compatible compiler be to the detriment of clang and > llvm? No one is trying to break mingw here, merely add support for something Just to make stuff clear: I just wanted proper naming which will be non-confusing. Right now we have: - isTargetWindows() which really means "msvc-compabile" - isTargetWin32() which means &quo...

Hi guys, I can't see virtio in releng/9.1, is there any particular reason why it isn't going to be included given that it works reasonable well (and is optional anyway, so not likely to be detrimental)? Thanks, Joe

In the documentation, it says that optimize "should only be called when the index will no longer be updated very often, but will be read a lot". Does this mean it actually has a detrimental impact on updates and inserts? In my project there will be many more reads than updates, but there will still be a lot of updates. So should I be calling Optimize once a day or something like that, during a low traffic time, or is that going to make updates slower? What are your recommendations f...

I found out today that Google Chrome is now available for Linux. However, and this is a big but: $ sudo rpm -ivh google-chrome-beta_current_x86_64.rpm Password: warning: google-chrome-beta_current_x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 7fac5991 error: Failed dependencies: lsb >= 3.2 is needed by google-chrome-beta-4.0.249.30-33928.x86_64 xdg-utils is needed by

Hello All, The current implementation of the CFG simplification is loop-agnostic. In the past I have observed that it can perform transformations that can be detrimental to the loop structure. One example that I recall, is converting a loop like this: while (...) { ... if (cond) continue; ... } into two nested loops. Specifically, the "continue" branch would go back to the loop header making it appear as if there were tw...

For whatever reason, patches posted to the Phabricator website still aren't being sent to the mailing list, making it difficult for us to review them. I've raised this issue a couple of times in the last few weeks. In practice this has a detrimental effect to the development workflow because it means that code is being seen only by a small group of individuals who have web accounts. The code isn't hitting llvm-commits or cfe-commits where the majority of code maintainers use the mailing lists for review. At this point I think Phabri...

...rayRef > shouldn't be named. For my case, since the caller is forced to use > `foo(makeTempArrayRef("string"))`, it's easier to make safe API changes. Yep - the convenience of one-element->ArrayRef is "cute" at best, I think. Having to wrap it doesn't seem detrimental. Would have to look at some numbers, though (if we could easily gather the number of instances of this - I'm not sure of the easiest way to do that, given the build system likes to stop after it sees an error). I'm not sure if the "Temp" in the name would be a sufficient deterr...

...9;s API. It is unfortunate that the C preprocessor is so bad at this sort of thing. 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. 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/

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.

...8, 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. > > More specifically, this impacts the tyranical :) 80 column limit we > have: > > > DEBUG(cout << "whatever stuff here" << yeah &lt...

...justin.holewinski at gmail.com> wrote: > That sounds like a missed multi-threading issue with LLVM. I can't > imagine why the user should be forced to serialize creation of MCContext > objects. I would suggest filing a bug for this. A simple lock probably > wouldn't be too detrimental to performance here, since MCContext objects > shouldn't be created too often. > > The deeper question is why we are even checking a "global" here in the first place? It goes against LLVM's library-based design. So I don't think introducing locking around this is th...

...deGenPrepare” and I > assume you reffer to CodeGenPrepare::optimizeSelectInst. I will try to > play a bit with that possibly later today. At first glance, it looks to me > that for targets that do not support ’select’ at all, the fact that the > function exits early for ‘OptSize’ can be detrimental, because this will > just leave ALL existing selects in the code anyway. As said, I will try to > play with that later, but right now it looks to me that maybe we should > check for TLI->isSelectSupported earlier in the function, to get some > more opportunities to such targets wi...