similar to: [LLVMdev] Target-specific code in non-Target part of LLVM

On 01/13/2017 10:19 AM, Krzysztof Parzyszek via llvm-dev wrote: > Hi Catello, > > LLVM does have a "loop idiom recognition" pass which, in principle, > does exactly that kind of a thing: it recognizes loops that perform > memcpy/memset operations. It does not recognize any target-specific > idioms though and there isn't really much in it that would make such

The high level of what happens is that __builtin_eh_return forces a spill of all the non-volatile registers. The unwinder then has a starting point for populating and adjusting those non-volatile registers. This approach usually requires that the function calling __builtin_eh_return be built without optimizations, because the optimizer will then remove the spills. From: llvm-dev

On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/19/2018 7:21 PM, 陳韋任 wrote: >> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? > > Our exception handling runtime uses __builtin_eh_return. Does this mean that you know what it

On 1/22/2018 8:40 AM, David Chisnall wrote: > On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 1/19/2018 7:21 PM, 陳韋任 wrote: >>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? >> >> Our exception handling

I don't remember the details of the particular case where we encountered this, but I think the loop started with the condition check and ended with an unconditional branch back to the beginning. -- Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development -----Original Message----- From: Philip Reames <listmail at philipreames.com> Sent: Thursday, May 30, 2019 3:00 PM

On 2/12/2016 9:47 PM, Vince Harron wrote: > Are you building LLDB? Im guessing that is where the failure is I'm building LLVM. The failure in the buildbot happens when compiling HexagonFrameLowering.cpp: ---------- FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /TP /DWIN32 /D_WINDOWS /W4 -wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351 -wd4355 -wd4456

On Hexagon, unguarded loops cannot be converted to hardware loops. If the loop's latch branch alone handles the iteration count, including the possibility of 0, then the loop cannot be converted to a hardware loop, because hardware loops must iterate at least once. If the entire loop is guarded against zero iteration count, we can put the loop setup in the preheader, since at that point the

Hi, Is there a mechanism in place to use the new pass manager with target-specific passes added (at the moment) via addIRPasses in TargetPassConfig? I did see any code related to that, did I miss something? Is it in plan? -- Krzysztof Parzyszek kparzysz at quicinc.com AI tools development

> On Jul 3, 2019, at 4:43 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -----Original Message----- > From: David Greene <dag at cray.com> > Sent: Wednesday, July 3, 2019 2:44 PM > To: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> > Cc: Krzysztof Parzyszek <kparzysz at quicinc.com> > Subject: [EXT] Re:

On 7/16/2013 11:38 PM, Andrew Trick wrote: > Since introducing the new TargetTransformInfo analysis, there has been some confusion over the role of target heuristics in IR passes. A few patches have led to interesting discussions. > > To centralize the discussion, until we get some documentation and better APIs in place, let me throw out an oversimplified Straw Man for a new pass pipline.

On Jul 29, 2013, at 9:05 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/16/2013 11:38 PM, Andrew Trick wrote: >> Since introducing the new TargetTransformInfo analysis, there has been some confusion over the role of target heuristics in IR passes. A few patches have led to interesting discussions. >> >> To centralize the discussion, until we get

I only see Hexagon has such optimization, is there any reason that Hexagon need this? No existing optimization does similar thing? Thanks, Regards, chenwj 2017-06-14 21:51 GMT+08:00 Krzysztof Parzyszek <kparzysz at codeaurora.org>: > On 6/14/2017 8:16 AM, 陳韋任 wrote: > >> Sounds like you break a single getelementptr into a few smaller ones, >> then do CSE-like

2018-01-19 23:00 GMT+08:00 Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org>: > On 1/15/2018 6:49 AM, 陳韋任 via llvm-dev wrote: > >> - EH_RETURN: >> >> I see some targets define their own EH_RETURN SDNode, others don't. >> What is EH_RETURN, and under what circumstances I should define my own >> EH_RETURN SDNode? >> > > This

Krzystof, Is this partly due to hardware loops not being common? I'm curious, we do something very similar for similar reasons. On Wed, Jun 14, 2017 at 10:23 AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 6/14/2017 9:05 AM, 陳韋任 wrote: > >> I only see Hexagon has such optimization, is there any reason that >> Hexagon need this?

Thank you :) If you mean this field, it looks everything is ok: field bits<16> Inst = { 0, 1, 1, 0, 1, 0, 0, 0, 0, 0, Dr{2}, Dr{1}, Dr{0}, At{0}, 0, 0 }; Is possible that the problem might be on the TestAsmParser.cpp side? On Thu, Sep 17, 2015 at 4:18 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 9/17/2015 9:04 AM, Krzysztof Parzyszek via llvm-dev

Thanks Krzysztof. That's very helpful - I was missing the distinction between a register containing an undefined value and a register marked as containing an undefined value. Cheers! On 1/23/18, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Send llvm-dev mailing list submissions to > llvm-dev at lists.llvm.org > > To subscribe or unsubscribe via the World Wide Web,

Hi paulr, Thank you for your response :) Hi Krzysztof, This is really helpful! Thank you for your guidance!! I would like to trace the Hexagon's llvm implementation. I am very interested on how Hexagon implement instruction pattern matching, instruction scheduling, and register allocation, could you give me some suggestions or reading lists to help me understand Hexagon's llvm

Examples of complex instructions? Hexagon has a cmpy instruction for complex multiplication, although it works on int16-based values. There is a whole set of these instructions (with various saturation/rounding behaviors), but each one of them can multiply two complex numbers (where a complex number is represented as two 16-bit values in a 32-bit register). That's a fairly complex pattern to

I missed the proposal for a first-class complex type, so I was thinking about working directly on pairs of numbers. I still think that intrinsics are better than a complex type. Intrinsics can be type-agnostic (i.e. overloaded), which would allow them to operate on complex number with any underlying type. Most applications want floating-point values, but on Hexagon we may want to use int16.

The associated patch caused a compilation problems on Hexagon: https://bugs.llvm.org/show_bug.cgi?id=43302 The splitting of a live interval should not be done automatically upon creation. Calling LIS->getInterval(Reg) should not go around changing the code behind the scenes. There is already a function “splitSeparateComponents” that does that. It should be added where it’s missing. --