similar to: [LLVMdev] this file was developed by ...

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] this file was developed by ..."

2007 Dec 14
0
[LLVMdev] this file was developed by ...
> Does anyone have a problem with changing this to: > > // This file is distributed under the University of Illinois > Open Source // License. See LICENSE.TXT for details. > > And leaving this whole business to our friendly version > control system (e.g. svn annotate), which has the perfect > answer all the time? Certainly I don't have a problem, I just want to point
2007 Dec 16
1
[LLVMdev] this file was developed by ...
Hi > > > Does anyone have a problem with changing this to: > > > > // This file is distributed under the University of Illinois > > Open Source // License. See LICENSE.TXT for details. > > > > And leaving this whole business to our friendly version > > control system (e.g. svn annotate), which has the perfect > > answer all the time? > >
2013 Jul 14
0
[LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the
2006 Aug 11
1
[BioC] problem loading affycoretools (more details)
Hi again, I have been playing around with the order of loading packages, and as far as I can tell, there's nothing specific with affycoretools that's causing my Rgui to crash (i.e., shuts down and the Microsoft 'please send error report' box pops up). Instead, it has something to do with the order & type of packages that are loaded that add items to the menu bar by
2007 Aug 23
5
[PATCH] Fix preemptible lazy mode bug
I recently sent off a fix for lazy vmalloc faults which can happen under = paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a = bit on fixing this. I neglected to notice that since the new call to = flush the MMU update queue is called from the page fault handler, it can = be pre-empted. Both VMI and Xen use per-cpu variables to track lazy = mode state, as all previous
2007 Aug 23
5
[PATCH] Fix preemptible lazy mode bug
I recently sent off a fix for lazy vmalloc faults which can happen under = paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a = bit on fixing this. I neglected to notice that since the new call to = flush the MMU update queue is called from the page fault handler, it can = be pre-empted. Both VMI and Xen use per-cpu variables to track lazy = mode state, as all previous
2017 Sep 04
2
llvm-dev Digest, Vol 159, Issue 2
Hal, Tobias, et al. – I am strongly in favor of seeing a broader range of loop transformations, supported by strong dependence analysis, added to LLVM, and the Polly infrastructure seems to be by far our best bet to make that happen. I have a couple of questions: 1) Integer constraint libraries like ISL (and Omega, which I used extensively in a previous project) are fundamentally solving
2017 Feb 01
2
[RFC] IR-level Region Annotations
From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Tuesday, January 31, 2017 9:03 PM To: Tian, Xinmin <xinmin.tian at intel.com> Cc: Sanjoy Das <sanjoy at playingwithpointers.com>; Adve, Vikram Sadanand <vadve at illinois.edu>; llvm-dev at lists.llvm.org; llvm-dev-request at lists.llvm.org Subject: Re: [llvm-dev] [RFC] IR-level Region Annotations On Jan 31,
2017 Feb 01
2
[RFC] IR-level Region Annotations
In this case, inliner is educated to add all local variables to the tag of enclosing parallel region, if there is enclosing parallel region. In our icc implementation, it is even simple, as we have routine level symbol table, the inliner adds ”private” attribute to those local variables w/o checking enclosing scope, the parallelizer does check and use it. Xinmin From: mehdi.amini at apple.com
2017 Jan 20
9
[RFC] IR-level Region Annotations
Hi Sanjoy, Yes, that's exactly what we have been looking at recently here, but the region tags seem to make it possible to express the control flow as well, so I think we could start with reg ions+metadata, as Hal and Xinmin proposed, and then figure out what needs to be first class instructions. --Vikram Adve > On Jan 19, 2017, at 11:03 PM, Sanjoy Das <sanjoy at
2017 Aug 18
2
RFC: Resolving TBAA issues
On 08/16/2017 01:59 PM, Ivan A. Kosarev via llvm-dev wrote: > Hal, Daniel, > > Thanks for your responses. Here's a quick formal introduction to the > proposed approach follows. I also attached a couple files to put some > visibility on implementation details. We'd love to hear from you > gentlemen and LLVM community in general on how this fits what you know > about
2006 Feb 21
7
Validation issues
I have a form. Everything submits into the database if I don''t have any validation rules. When I put these rules: validates_uniqueness_of :title, :message => "already exists in database" validates_presence_of :title I get this error (which seems weird because I am not validating against that): You have a nil object when you didn''t expect it! You
2017 Jan 13
2
[RFC] IR-level Region Annotations
> (d) Add a small number of LLVM intrinsics for region or loop annotations, > represent the directive/clause names using metadata and the remaining > information using arguments. > > Here we're proposing (d), I think this would serve the goal of communicating source-level directives and annotations down to LLVM passes and back-ends, while deferring inlining and
2017 Jan 20
5
[RFC] IR-level Region Annotations
> On Jan 20, 2017, at 10:44 AM, Tian, Xinmin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sanjoy, the IR would be like something below. It is ok to hoist alloca instruction outside the region. There are some small changes in optimizer to understand region-annotation intrinsic. > > { void main() { > i32* val = alloca i32 > tok =
2017 Feb 01
2
[RFC] IR-level Region Annotations
> On Jan 31, 2017, at 10:59 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > > >   <> > From: mehdi.amini at apple.com <mailto:mehdi.amini at apple.com> [mailto:mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>] > Sent: Tuesday, January 31, 2017 9:03 PM > To: Tian, Xinmin <xinmin.tian at intel.com <mailto:xinmin.tian at
2013 Jul 31
1
[LLVMdev] [Proposal] Speculative execution of function calls
On 31 July 2013 11:56, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > The slightly orthogonal question to safety is the cost of execution. For > most intrinsics that represent CPU instructions, executing them > speculatively is cheaper than a conditional jump, but this is not the case > for all (for example, some forms of divide instructions on in-order RISC >
2017 Mar 08
3
[RFC][PIR] Parallel LLVM IR -- Stage 0 --
I assume the referring case is something like below, right? #pragma omp parallel num_threads(n) { #pragma omp critical { x = x + 1; } } If that is the case, the programmer is already writing the code that is not "serial equivalent". Our representation for parallelizer is %t = @llvm.region.entry()["omp.parallel"(),
2017 Sep 04
2
[RFC] Polly Status and Integration
On Mon, Sep 4, 2017, at 20:49, Hal Finkel via llvm-dev wrote: > [tying to original thread] > > On 09/04/2017 01:37 PM, Adve, Vikram Sadanand via llvm-dev wrote: > > Hal, Tobias, et al. – > > > > I am strongly in favor of seeing a broader range of loop transformations, supported by strong dependence analysis, added to LLVM, and the Polly infrastructure seems to be by far
2017 Feb 01
0
[RFC] IR-level Region Annotations
> On Jan 31, 2017, at 7:53 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > > In this case, inliner is educated to add all local variables to the tag of enclosing parallel region, if there is enclosing parallel region. So isn’t it a good example that shows that your intrinsic *cannot* be opaque and that IR passes need to be modified to handle not only the IR-region
2017 Jan 19
4
[RFC] IR-level Region Annotations
Hi Johannes, > I am especially curious where you get your data from. Tapir [0] (and to > some degree PIR [1]) have shown that, counterintuitively, only a few changes > to LLVM passes are needed. Tapir was recently used in an MIT class with a > lot of students and it seemed to work well with only minimal changes > to analysis and especially transformation passes. TAPIR is an