similar to: llvm-dev Digest, Vol 164, Issue 6

Displaying 20 results from an estimated 20000 matches similar to: "llvm-dev Digest, Vol 164, Issue 6"

2018 Feb 03
0
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 5:56 PM Guenter Roeck <linux at roeck-us.net> wrote: > On 02/02/2018 04:27 PM, Chandler Carruth wrote: > > On Fri, Feb 2, 2018 at 4:23 PM Chandler Carruth <chandlerc at google.com > <mailto:chandlerc at google.com>> wrote: > > > > On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org > <mailto:dwmw2 at
2018 Feb 01
1
Customizing SBCC for lcov workflows
I’m working to implement Source Based Code Coverage in a workflow that uses lcov for report generation. We’ve customized our llvm-cov to add a command to convert the SBCC counter data to lcov’s ‘.info’ format. The problem is that the region-based counter definitions in SBCC can span source code regions that can contain blank lines (or lines with only comments). Converting this to lcov’s
2018 Feb 03
1
retpoline mitigation and 6.0
On 02/02/2018 04:27 PM, Chandler Carruth wrote: > On Fri, Feb 2, 2018 at 4:23 PM Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: > > On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org <mailto:dwmw2 at infradead.org>> wrote: > > On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev
2018 Feb 03
0
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 4:23 PM Chandler Carruth <chandlerc at google.com> wrote: > On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org> > wrote: > >> On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote: >> > >> > I saw the retpoline mitigation landed in r323155. Are we ready to >> > merge this to 6.0, or are
2018 Feb 07
3
retpoline mitigation and 6.0
On Wed, Feb 07, 2018 at 08:44:32PM +0000, David Woodhouse wrote: > On Wed, 2018-02-07 at 10:11 -0800, Guenter Roeck wrote: > > > On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse wrote: > > > Hm, please could we also have the %V asm constraint modifier? That > > > allows us to emit calls to the thunks from inline asm using the > > > register that the
2018 Feb 07
0
retpoline mitigation and 6.0
On Wed, 2018-02-07 at 10:11 -0800, Guenter Roeck wrote: > On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse wrote: > > Hm, please could we also have the %V asm constraint modifier? That > > allows us to emit calls to the thunks from inline asm using the > > register that the compiler chose for us: > > > >  asm volatile ("call
2018 Feb 03
4
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote: > > > > I saw the retpoline mitigation landed in r323155. Are we ready to > > merge this to 6.0, or are there any open issues that we're waiting > > for? Also, were there any followups I should know about? Also,
2018 Feb 09
2
retpoline mitigation and 6.0
On Fri, Feb 9, 2018 at 12:26 AM David Woodhouse <dwmw2 at infradead.org> wrote: > > > On Fri, 2018-02-09 at 02:21 +0000, David Woodhouse wrote: > > On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > > > > > > > > For now I'm just going to attempt to work around it like this in the > > > kernel, so I can concentrate on the
2018 Feb 09
3
retpoline mitigation and 6.0
I haven't read the all the emails in full detail, but it seems pretty clear that __x86_indirect_thunk and __llvm_retpoline_push do not do the same things. It sounds like __llvm_retpoline_push is equivalent to __x86_indirect_thunk except first it swaps the two words on the top of the stack. I arranged it this way because the x86 call instruction puts the intended return address on the top of
2018 Feb 07
0
retpoline mitigation and 6.0
The patch is up for review here: https://reviews.llvm.org/D42998 On Tue, Feb 6, 2018 at 4:58 PM Chandler Carruth <chandlerc at google.com> wrote: > Also, could you patch and test Clang with the Linux kernel after I make > this change? I'd like to know that we actually successfully call the > correct thunks and that they behave correctly. I'm not super worried, but >
2018 Feb 07
0
retpoline mitigation and 6.0
On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote: > > > > > > > That would be __x86_indirect_thunk but the kernel doesn't use it. > > > We use -mindirect-branch-register and only ever expect the compiler > > > to use the register versions which are
2018 Feb 07
0
retpoline mitigation and 6.0
On Tue, Feb 6, 2018 at 4:32 PM David Woodhouse <dwmw2 at infradead.org> wrote: > > > On Wed, 2018-02-07 at 00:26 +0000, Chandler Carruth wrote: > > On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at google.com> > wrote: > > On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org> > wrote: > > At this point, what we
2018 Feb 07
2
retpoline mitigation and 6.0
Also, could you patch and test Clang with the Linux kernel after I make this change? I'd like to know that we actually successfully call the correct thunks and that they behave correctly. I'm not super worried, but good to actually get this right. I'm am slightly more worried about the stack-based retpoline than the register ones just due to the overall lower amount of testing
2018 Feb 09
0
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 02:21 +0000, David Woodhouse wrote: > On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > > > > > For now I'm just going to attempt to work around it like this in the > > kernel, so I can concentrate on the retpoline bits: > >  http://david.woodhou.se/clang-percpu-hack.patch > > 32-bit doesn't boot. Built without
2018 Feb 07
2
retpoline mitigation and 6.0
On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse wrote: > On Wed, 2018-02-07 at 06:20 +0000, Chandler Carruth wrote: > > I've landed the patch in r324449. > > > > Before we merge this into two different Clang release branches and > > almost immediately release one of them, I would really like someone > > to confirm that this patch works well with the
2018 Feb 03
2
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 4:36 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Sat, 2018-02-03 at 00:23 +0000, Chandler Carruth wrote: > > > > Two aspects to this... > > > > One, we're somewhat reluctant to guarantee an ABI here. At least I > > am. While we don't *expect* rampant divergence here, I don't want > > this to become
2018 Feb 06
0
retpoline mitigation and 6.0
On Tue, 2018-02-06 at 22:08 +0000, Chandler Carruth wrote: > So, I was waiting to hear a definitive response on whether using > aliases is hard, and didn't see one here, which is why I haven't > responded further. > > However, a colleauge pointed me at an LKML thread where it seems > there *is* a definitive response? Aliases are hard when the compiler is directly
2018 Feb 07
2
retpoline mitigation and 6.0
On Wed, 2018-02-07 at 00:26 +0000, Chandler Carruth wrote: > On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at google.com > > wrote: > > On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org > > > wrote: > > > At this point, what we really want is for identical thunks to > > > have identical names — just like we do for
2018 Feb 09
0
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 12:54 +0000, David Woodhouse wrote: > On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote: > >  > > Did you get anywhere with the function attribute? Having isolated the > > next boot failure to "it goes away if I compile io_apic.c without > > retpoline", bisecting it per-function would help to further delay the > > bit where I
2018 Feb 02
1
Vector Splitting for Stackmap Operands
HI All, I am current working with SIMD instruction along with stackmap features. Recently I encountered a problem involving legalizing stackmap. In my stackmap, I record all the live values existing at the callsite. One of the operands in my stackmap is an illegal vector type for arm64 architecture ( *v4f64*) and requires vector splitting in order to legalize the node ( *v2f64*). However, I