similar to: [AArch64] Generated assembly differs depending on whether debug information is generated or not

Hi Paul, thanks for your comments. This is PR37240 (https://bugs.llvm.org/show_bug.cgi?id=37240). I suspect this problem affects all targets; your patch D68076 would address it only for AArch64. Although I would suggest you do some careful measurements to determine the runtime performance effect, to decide whether this is acceptable. Yes, in principle the problem that instruction scheduling is

Hi Vedant, thanks for your answer and sorry for the late response. It seems like D68076 might not address the underlying issue here (e.g. it probably doesn't improve the situation for projects using `-g -fno-unwind-tables`?). Yes, D68075 is a somewhat conservative patch that aligns the behaviour on AArch64 (for GNU targets) that leads to consistent generated assembly. As you said it does not

Thanks. I've rebased this patch on top of the recent LLVM (it was straightforward) and applied it in my fork. It seems to have solved one of the problems I was having. Would LLVM be interested if I submit the updated version for the review? -- Danila From: Philip Reames [mailto:listmail at philipreames.com] Sent: Tuesday, August 13, 2019 19:01 To: Danila Malyutin <Danila.Malyutin at

I've noticed that there was an attempt to mitigate ExitValues problem in https://reviews.llvm.org/D12494 that went nowhere. Were there particular issues with that approach? -- Danila From: Philip Reames [mailto:listmail at philipreames.com] Sent: Saturday, August 10, 2019 02:05 To: Danila Malyutin <Danila.Malyutin at synopsys.com>; Finkel, Hal J. <hfinkel at anl.gov> Cc: llvm-dev

Hi Hal, I see. So LSR could theoretically counteract undesirable Ind Var transformations but it's not implemented at the moment? I think I've managed to come up with a small reproducer that can also exhibit similar problem on x86, here it is: https://godbolt.org/z/_wxzut As you can see, when rewriteLoopExitValues is not disabled Clang generates worse code due to additional spills,

There was this PR to use Jasmine: https://reviews.llvm.org/D20161 But I think it did not make it into tree. Kristof, any update on the issues you were encountering? We could move forward with that. I think we were pretty agnostic to which framework to use as long as it was not hard to install. JS Testing would be *really* good. I have debugged a lot of issues recently that ended up in the JS.

Hello, Recently I've come across two instances where Induction Variable Simplification lead to noticable performance regressions. In one case, the removal of extra IV lead to the inability to reschedule instructions in a tight loop to reduce stalls. In that case, there were enough registers to spare, so using extra register for extra induction variable was preferable since it reduced

On 11-06-02 6:56 AM, Anton Korobeynikov wrote: > Hi Chip, > >> Because of all this, it's hard to reconstruct the SEH information from >> the MachineMove array. I have thought about adding a new array specific >> to SEH information, but I'm not sure how you guys would feel about that. >> Any ideas on how to solve this problem? > Same problem with

On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote: > On 11-06-02 6:56 AM, Anton Korobeynikov wrote: >> Hi Chip, >> >>> Because of all this, it's hard to reconstruct the SEH information from >>> the MachineMove array. I have thought about adding a new array specific >>> to SEH information, but I'm not sure how you guys would feel about

Hello. We've started using LNT and found it very handy. However, we found that LNT web UI is missing some features to help our use-cases. We'd like to add them (and already started doing so) but it's hard to add them without breaking existing features/workflows because while LNT has some python CLI test coverage the dynamic Web part (mainly JS UI) is not really tested. So our question

On Thu, Jun 25, 2020 at 11:43 AM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Thu, Jun 25, 2020 at 11:22 AM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> What this means for LLVM is that everyone will have to completely stop using history rewriting operations. No more rebase, squash, amend, etc. > > This is also incorrect. Most

> On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hello, > > Regarding the problem of debug range for optimized code. > Currently a DEBUG_VALUE will be inserted after the <def>vregX > DEBUG_VALUE are only valid until the end of the current MachineBasicBlock. That's the main problem. > Why not simply iterate over all uses

The most obvious place where it is lacking at the moment is that it only supports DBG_VALUEs in registers. Adding support for constant values, memory locations, and fp constants would be a big win! thanks, Adrian > On May 11, 2016, at 2:52 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > In retrospect I totally agree with you. I am looking at LiveDebugValue again to see

> On May 11, 2016, at 2:09 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Good point. > > Currently yes a DEBUG_VALUE "x", vreg0 will be added in BB2. Now I realize this might be wrong in some (corner?) cases where vreg0 no longer refer to "x" > > My fix would be to propagate the DEBUG_VALUE only if "x" is associated with only a

I spent some time digging into a Valgrind report of uninitialized values in LLVM r287520 built using itself. (One of quite a few such reports that comes up during a "make check".) I could use another set of eyes on the issue if someone has time. This command gives me an error: valgrind -q ./bin/llc < /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon

> On May 12, 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Here is a specific case that make the debugging experiences degraded on my target: > This is a loop simplified CFG: > > BB#0: > %R5<def> = OR_rr %R0, %R49 // this is %R5 only def. > DBG_VALUE %R5, %noreg, !"argc", <!18>; line no:4 > Successors

Just want to emphasize that on x86-64 and using Valgrind: LLVM compiled with LLVM gets 360 unexpected test fails LLVM compiled with GCC gets 22 unexpected test fails Of course I don't know how many of these are caused by this bitfield speculation issue. John On 11/21/2016 10:48 PM, regehr via llvm-dev wrote: > Alright, here's what seems to be happening... > > The testcase

Hi all, An early implementation of extending debug ranges and providing multiple location support is done here: http://reviews.llvm.org/D11933 Design document: https://docs.google.com/document/d/1noDVWTvTWBdYdweICPBwvwyt8QvX4KHl7j3XKNSg1nE/edit?usp=sharing On Jun 24, 2015, at 12:12 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: Hi Adrian, You might want to take a look at abandoned

Hello David, I believe Johannes already answered your questions, but just to clarify the things fully: yes, we are going to submit an application to participate in GSoC this year as usual. I will take care of necessary paperwork and stuff. Currently we're collecting the list of summer projects here and there. It's perfectly fine to have the lists from sub-projects to be posted on their

Hi Igor, > It sounds like the linker has to be aware of the .eh_frame section details to be able to generate .eh_frame_hdr and eliminate duplicate CIEs, right? Yes, a linker needs some details but not all of them. It needs to know sizes of records and initial locations (PC Begin) to find out which functions FDEs belong to. > So, is there any difference whether it knows that in one place