search for: detriments

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?

> 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

> 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

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.

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,

On Thu, Mar 28, 2013 at 12:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Eric Christopher <echristo at gmail.com> writes: > > > In my opinion none of these are irrelevant. Mingw and cygwin are separate > > ABIs that deal with some C compatibility (problems mentioned in this > thread > > are important here too) and give you the ability to work with low

> 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 "everything on windows", so

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,

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

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.

On Fri, Aug 22, 2014 at 10:16 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> On 2014-Aug-21, at 10:39, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Thu, Aug 21, 2014 at 10:34 AM, Reid Kleckner <rnk at google.com> wrote: >>> Is there some way we can get lifetime extension of temporaries to kick in >>> here? >>

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 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 Thu, May 23, 2013 at 8:13 AM, Justin Holewinski < 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

Changing the order of the checks in CodeGenPrepare::optimizeSelectInst() sounds good to me. But you may need to go further for optimum performance. For example, we may be canonicalizing math/logic IR patterns into 'select' such as in the recent: https://reviews.llvm.org/D67799 So if you want those to become ALU ops again rather than branches, then you need to do the transform later in