Displaying 20 results from an estimated 300 matches similar to: "[LLVMdev] [PATCH]: Add SparseBitmap implementation"
2007 Sep 04
0
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On Fri, Aug 31, 2007 at 08:10:33PM -0400, Daniel Berlin wrote:
> Suggestions, criticisms, etc, are welcome.
I haven't studied the implementation, but I have a few comments on
the interface, and some style comments, below.
> Index: include/llvm/ADT/SparseBitmap.h
> ===================================================================
> --- include/llvm/ADT/SparseBitmap.h (revision
2007 Sep 04
2
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On 9/4/07, Dan Gohman <djg at cray.com> wrote:
> On Fri, Aug 31, 2007 at 08:10:33PM -0400, Daniel Berlin wrote:
> > Suggestions, criticisms, etc, are welcome.
>
> I haven't studied the implementation, but I have a few comments on
> the interface, and some style comments, below.
>
> > Index: include/llvm/ADT/SparseBitmap.h
> >
2007 Sep 04
0
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On Tue, Sep 04, 2007 at 10:35:10AM -0400, Daniel Berlin wrote:
> On 9/4/07, Dan Gohman <djg at cray.com> wrote:
> > On Fri, Aug 31, 2007 at 08:10:33PM -0400, Daniel Berlin wrote:
> > > + template <int ElementSize>
> > > + class SparseBitmap {
> >
> > Do you expect clients will often want custom ElementSize values? Otherwise,
> > it seems
2007 Sep 04
6
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On 9/4/07, Dan Gohman <djg at cray.com> wrote:
> On Tue, Sep 04, 2007 at 10:35:10AM -0400, Daniel Berlin wrote:
> > On 9/4/07, Dan Gohman <djg at cray.com> wrote:
> > > On Fri, Aug 31, 2007 at 08:10:33PM -0400, Daniel Berlin wrote:
> > > > + template <int ElementSize>
> > > > + class SparseBitmap {
> > >
> > > Do you
2007 Sep 07
0
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On Tue, 4 Sep 2007, Daniel Berlin wrote:
>> insert/push_back without making copies. Either of these approaches would
>> also fix what looks like a leak in operator&=, where elements are erased
>> from the list without being deleted.
>
> I seriously considered not using indirection, but it made a lot of the
> functions more annoying, and it didn't seem worth the
2007 Sep 07
1
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On 9/7/07, Chris Lattner <sabre at nondot.org> wrote:
> On Tue, 4 Sep 2007, Daniel Berlin wrote:
> >> insert/push_back without making copies. Either of these approaches would
> >> also fix what looks like a leak in operator&=, where elements are erased
> >> from the list without being deleted.
> >
> > I seriously considered not using indirection,
2007 Sep 05
0
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On Sep 4, 2007, at 4:36 PM, Daniel Berlin wrote:
> Also, someone on IRC asked about the weird function naming
> conventions. I know most of llvm uses mixedCase, but i copied the
> style of BitVector, which has a weird mix. I'm happy to change it :)
Yes please. By default, it is a good idea to follow llvm coding
conventions instead of copying violation of coding style from
2007 Sep 05
0
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On Sep 4, 2007, at 4:36 PM, Daniel Berlin wrote:
[snip]
Don't forget to update ProgrammersManual.html "Picking the Right
Data Structure for a Task" section. :)
-
Devang
2007 Sep 06
2
[LLVMdev] [PATCH]: Add SparseBitmap implementation
On 9/4/07, Devang Patel <dpatel at apple.com> wrote:
>
> On Sep 4, 2007, at 4:36 PM, Daniel Berlin wrote:
>
> [snip]
>
> Don't forget to update ProgrammersManual.html "Picking the Right
> Data Structure for a Task" section. :)
It doesn't talk about bitvector at all. I'm not sure whether i should
add it to set like containers, or add a section
2010 Feb 08
1
About scales in graphics
Hi,
I'm building two graphics just changing the scale to show
the graphic illusion.
The first graph would be 'correct'.
atend = c(410,430,450,408,408,405)
names(atend) = c('Janeiro', 'Fevereiro', 'Mar?o', 'Abril',
'Maio', 'Junho')
barplot(atend, las=1, xlab='Meses', ylab='N?mero de
atendimentos',
2009 May 12
1
[LLVMdev] SparseBitVector compile warning
The warning is:
R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(58) : warning
C4099: 'llvm::ilist_sentinel_traits<llvm::SparseBitVectorElement<ElementSize>>'
: type name first seen using 'struct' now seen using 'class'
R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(275) :
see reference to class template instantiation
2012 Sep 04
2
[LLVMdev] [NVPTX] Backend cannot handle array-of-arrays constant
I think our test case demonstrates that requiring the array item being
initialized to be constant is incorrect. NVPTX does not crash anymore
and produces correct result with the following change:
--- NVPTXAsmPrinter.cpp 2012-09-03 15:14:00.000000000 +0200
+++ NVPTXAsmPrinter.cpp 2012-09-04 15:47:17.859398193 +0200
@@ -1890,17 +1890,15 @@
case Type::ArrayTyID:
case Type::VectorTyID:
case
2012 Sep 06
0
[LLVMdev] [NVPTX] Backend cannot handle array-of-arrays constant
On 09/04/2012 09:57 AM, Dmitry N. Mikushin wrote:
> I think our test case demonstrates that requiring the array item being
> initialized to be constant is incorrect. NVPTX does not crash anymore
> and produces correct result with the following change:
>
> --- NVPTXAsmPrinter.cpp 2012-09-03 15:14:00.000000000 +0200
> +++ NVPTXAsmPrinter.cpp 2012-09-04 15:47:17.859398193 +0200
>
2020 Jul 30
2
Normalize a SCEV Expression
Hi,
I have a SCEV like this: {16,+,8}. Say that this came from a loop like:
int64_t *p;
for (int64_t i = 0; i < ...; ++i)
p[i+2]...
And assuming that I'm on a 64-bit machine. What I would like to do is
normalize it
like that, basically this: {2,+,1} i.e. map it to the index.
Now, I tried to get the underlying element size of the pointer, then
getUDivExpr(OriginalSCEV, ElementSize); But
2003 Apr 08
1
Can't do Landscape with ManualFeed
Hi:
I am haviong problems with Landscape mode on our HP printers (many models).
I am running 2.2.7a on two different servers. One is using the "old style"
printing (using "printer driver file" parameter). The other is using the
newer printing system. It is the same code on both. Both are Solaris
systems. For the old one, the drivers are installed on the client, for the
2012 Sep 04
0
[LLVMdev] [NVPTX] Backend cannot handle array-of-arrays constant
NVCC successfully handles the same IR, if we try to process the same
.cu file with clang+nvptx and nvcc:
CLANG/NVPTX:
=============
$ cat dayofweek.cu
__attribute__((device)) char yweek[7][4] = { "MON", "TUE", "WED",
"THU", "FRI", "SAT", "SUN" };
$ clang -cc1 -emit-llvm -fcuda-is-device dayofweek.cu -o dayofweek.ll
$ cat
2012 Sep 03
2
[LLVMdev] [NVPTX] Backend cannot handle array-of-arrays constant
Dear all,
Looks like the NVPTX backend cannot handle array-of-arrays contant
(please see the reporocase below). Is it supposed to work? Any ideas
how to get it working? Important for our target applications.
Thanks,
- Dima.
$ cat test.ll
; ModuleID = '__kernelgen_main_module'
target datalayout =
2011 Nov 19
0
[LLVMdev] How to make Polly ignore some non-affine memory accesses
On 11/18/2011 01:34 PM, Marcello Maggioni wrote:
> Ok , this is what I believe is the final patch that adds the
> non-affine accept functionality to Polly, this should have no issues.
>
> I added three tests, two in ScopInfo (two simple tests, one expected
> fail and one success based on the same source) and one in CodeGen that
> verifies that the code is generated.
>
> The
2009 Mar 14
1
Problem with figure size when embedding fonts
Dear Colleagues:
I need to make a graphic that uses the Nimbus rather than Helvetica font
family so that the font can be embedded in the encapsulated postscript
file. This is to satisfy a requirement from a journal for electronic
submission of figures. I do the following:
postscript('lowess.eps', onefile=FALSE, pointsize=18, horizontal=FALSE,
family='NimbusSan')
2014 Mar 02
3
[LLVMdev] [RFC] The coding standard for "struct" should be relaxed or removed
On Mar 1, 2014, at 7:15 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Sat, Mar 1, 2014 at 5:59 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> The current guidelines [1] on the use of the struct keyword are too
> restrictive and apparently ignored. They limit the use of struct to
> PODs, citing broken compilers.
>
> The guidelines are