similar to: [LLVMdev] Illegal Optimization(?): Combining empty type instances

On Tue, 1 Nov 2005, Evan Jones wrote: > I think I may have found an illegal optimization in LLVM. The problem is that > if you have an empty type LLVM optimizes it away so it produces weird > results. The assembler output from llvm-gcc clearly outputs the "alloca" > instructions, so some other pass is removing them. I doubt if any real > program relies on this

Reid raised this issue in a bug comment that I thought should be discussed on the mailing list: http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=540 > I'm really not sure this is wise unless there is consensus that lli > should always be a multi-threaded program. Certainly, there's enough > problems with multi-threading that this could break many tests. I'd > like some

On May 19, 2005, at 19:10, Chris Lattner wrote: >> Now that 1.5 has been released, would it be possible to have some >> discussion about if linking the JIT with a thread library is the >> direction that should be taken? I don't see any alternative except >> having separate "threaded" and "unthreaded" JITs, and requiring the >> user to know

Evan Jones wrote: > On Nov 23, 2005, at 22:49, Jeff Cohen wrote: > >> News to me. I do it all the time. Notice the "win32" directory >> under the root :) > > > Okay, so I spoke about something that I don't really know about, since > I don't use Windows. But what was the whole "Still can't compile > backend of frontend on

On Nov 23, 2005, at 22:49, Jeff Cohen wrote: > News to me. I do it all the time. Notice the "win32" directory under > the root :) Okay, so I spoke about something that I don't really know about, since I don't use Windows. But what was the whole "Still can't compile backend of frontend on Windows" discussion about? My impression is that LLVM only builds

I am trying to generate LLVM code that references a global array. Unfortunately, while I am generating the code I do not know the final length of the array, as I add elements to it as my compiler goes along. What is the best way to do this in LLVM? Ideally, I would be able to define the GlobalVariable array and change its length later on. I would love for it to have the correct length so I

On Nov 23, 2005, at 18:17, Reid Spencer wrote: >> So this comment means that I should attempt to theoretically support >> Windows, and close the current archive file before updating it? > If you use sys::Path, it is not "theoretically" supported, it is > supported. Well, except of course that it isn't currently possible to build LLVM on Windows. Hence this is a

I ran the LLVM regression tests today (via make check) and noticed that llvm-ranlib crashes with a Bus Error on my test system (a fairly old RedHat 9 system), using the latest CVS version. I did some digging and I think I know what the problem is, and I have attached a quick and dirty patch that fixes the problem for me, but I need a suggestion about how it should be integrated properly. Here

Evan, Your patch uses an operating system call that is not portable. All non-portable code needs to be located in the lib/System library. I'm not sure why this problem appears on an old Red Hat system. Perhaps the C++ io library is not up to snuff on that platform? What compiler are you using? Reid. Evan Jones wrote: > I ran the LLVM regression tests today (via make check) and

Hi list I have a data frame I would like to loop over. To begin with I would like crosstabulations using the first variabel in the data frame, which is called "meriter". > table(meriter[[1]], meriter[[3]]) ja nej Annan 0

On Nov 22, 2005, at 23:59, Reid Spencer wrote: >> = {0, >> 0, 4, 0}}} >> (gdb) p archPath >> $3 = {path = {static npos = 4294967295, >> _M_dataplus = {<allocator<char>> = {<No data fields>}, >> _M_p = 0x83545f4 "temp.GNU.a5\b"}, static _S_empty_rep_storage = > What's with the "5\b" at the end? Looks

On Nov 22, 2005, at 17:18, Reid Spencer wrote: > Your patch uses an operating system call that is not portable. All > non-portable code needs to be located in the lib/System library. Yep! I know. That is why I posted it for discussion. I'm not sure if this is the "right" way to fix the problem, or if there is a different fix that should be applied (like perhaps copying the

On Wed, 18 May 2005, Evan Jones wrote: > On May 14, 2005, at 13:28, Reid Spencer wrote: >>> This is definitely *not* something that should go in before 1.5 is >>> released, but I would love to see it integrated shortly after. >> Okay. > > Now that 1.5 has been released, would it be possible to have some discussion > about if linking the JIT with a thread

Evan Jones wrote: > On Nov 23, 2005, at 18:17, Reid Spencer wrote: > >>> So this comment means that I should attempt to theoretically support >>> Windows, and close the current archive file before updating it? >> >> If you use sys::Path, it is not "theoretically" supported, it is >> supported. > > > Well, except of course that it

On Nov 22, 2005, at 19:10, Reid Spencer wrote: > 1. What is the path name associated with TmpArchive? If its the same > as the path name associated with archPath then that's a bug, probably > introduced when Path::makeUnique is called from > Path::createTemporaryFileOnDisk which is called from line 377 of > ArchiveWriter.cpp. This does not appear to be the problem. I

Evan Jones wrote: > On Nov 23, 2005, at 12:08, Reid Spencer wrote: > >>> However, it would be possible to use a stringstream for this. >> >> Aggg! No! Those perform horribly with anything more than a small >> amount of data. Some Archive files can be huge (e.g. not fit in memory). > > > An archive can be too big to fit in memory? That would be a BIG

On May 13, 2005, at 20:30, Evan Jones wrote: > should LLVM always be capable of executing multithreaded programs? On a related note, I've updated my patch to fix the bug that I found in it, and I discussed on the mailing list last month. The details can be found in the bug: http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=418 This is definitely *not* something that should go in before 1.5

On May 14, 2005, at 13:28, Reid Spencer wrote: >> This is definitely *not* something that should go in before 1.5 is >> released, but I would love to see it integrated shortly after. > Okay. Now that 1.5 has been released, would it be possible to have some discussion about if linking the JIT with a thread library is the direction that should be taken? I don't see any

On Nov 2, 2005, at 16:39, Chris Lattner wrote: > 4. Replace the old GV with the new GV using code that looks like this: > > OldGV->replaceAllUsesWith(ConstantExpr::getCast(NewGV, > OldGV->getType()); > OldGV->eraseFromParent(); > > At the end of this, any instructions or other globals that referenced > the temporary global will now reference the new one.

I am somewhat confused about how I should go about releasing LLVM types. Some types are owned by a Module, and others I am not sure about. Are there any general rules or guidelines that I should be aware of? It appears to me that whenever I am passing a "new" object into a container type like a module or basic block that the container owns the object. Is that accurate? If this is