similar to: [LLVMdev] Should the Constant* pointer be declared with "const" or not?

Try to keep things on the mailing list, if possible.  That usually means hitting "reply to all".  (I forgot earlier, myself.  Sorry.) ----- Forwarded Message ----- > From: Stepan Dyatkovskiy <STPWORLD at narod.ru> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: > Sent: Wednesday, January 18, 2012 1:50 PM > Subject: Re: [LLVMdev] Should the Constant*

Sorry!  Forgot to CC the list. ----- Forwarded Message ----- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Stepan Dyatkovskiy <stpworld at narod.ru> > Cc: > Sent: Wednesday, January 18, 2012 1:31 PM > Subject: Re: [LLVMdev] Should the Constant* pointer be declared with "const" or not? > > Hello Stepan, > > The LLVM source code uses a

I'd really rather not do this. Faking that large zero filled array is represented with ConstantArray means that the compiler will inevitably end up calling getOperand on each of those elements, burning a ton of compile time. -Chris On Jan 20, 2012, at 12:16 PM, Stepan Dyatkovskiy <STPWORLD at narod.ru> wrote: > Hi all. I propose to use wrapper for this kind of constant objects.

Hi all. I propose to use wrapper for this kind of constant objects. Consider next code: Constant* C = reinterpret_cast<Constant*>(I->getOperand(idx)); Constant* ArrayItem; if (!isa<ConstantAggregateZero>(C)) ArrayItem = reinterpret_cast<Constant*>(I->getOperand(ArrItemIdx)); else ArrayItem = ZeroInt; Code analog within wrapper: ConstOrZero

Hi, I think Chris recently did this with ArrayRef - that might be a good template to base your solution on? Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stepan Dyatkovskiy Sent: 16 February 2012 06:36 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Question about "const" Hi all. I have a next

On Thu, May 24, 2012 at 12:44 AM, Stepan Dyatkovskiy <stpworld at narod.ru>wrote: > I just want to update test/Transforms/LowerSwitch/feature.ll that > already uses grep. > It uses grep + count, probably due to shorter construction. > If you are touching such a test, please convert it to FileCheck. Use of 'grep' in tests is an endless source of problems, and we are

I just want to update test/Transforms/LowerSwitch/feature.ll that already uses grep. It uses grep + count, probably due to shorter construction. -Stepan. Eric Christopher wrote: > > On May 24, 2012, at 12:12 AM, Stepan Dyatkovskiy wrote: > >> Hi all. I found that if you want to use grep with escape characters in >> lit, you should pass it within the double slash (\\). Since

Hi Stephan, I've been thinking about this a bit and have some more specific ideas, I'll write up a design and maybe implement it over the next few days. -Chris On Jan 21, 2012, at 11:50 PM, Stepan Dyatkovskiy <STPWORLD at narod.ru> wrote: > Hi Chris. The main question is how to implement ConstantAggregateXXXXX::getOperand? Should it be empty collection, or it must return the

Hi David, After merging we always remove body of "G" (function we want to merge with "existing" one). In case with "writeThunk" we could add such info for "G", but it would be just a single string: reference to first string of "G". Ideal way here, is to merge debug information itself, and provide "F" with information for "G"

Does anybody else have an opinion on this issue? I'm planning to submit a patch which would add a new get method for ConstantDataVector taking an ArrayRef<Constant*> and use that in the few places in constant propagation where convertToFloat is used. Let me know if you think there is a more obvious way to do it. Right now the only way to create a ConstantDataVector are those method:

Hi Anton, in a solution without CAZ, isNullValue can just return true when it sees the special "this ConstantArray is all zero" flag. So all the places that now look for CAZ can just use isNullValue instead and there need be no performance loss. That said, CAZ is more "in your force" so less likely to be forgotten about. Another interesting possibility is to handle more than

Now I see, that its to so trivial as I thought before. There are a lots of parser extensions that creates the symbols. And in each place we need insert add its location info. I also found that MCContext has several create symbols methods, but all these methods uses CreateSymbol private method. So I see two possible ways here: 1. To aggregate all GetOrCreate-like symbol methods inside the

Hi Chris. The main question is how to implement ConstantAggregateXXXXX::getOperand? Should it be empty collection, or it must return the item aggregated? -Stepan. 22.01.2012, 04:43, "Chris Lattner" <clattner at apple.com>: > Yep check out PR1324.  Doing something like this would be a great improvement. > > -Chris > > On Jan 21, 2012, at 9:42 AM, Duncan Sands

How many times will a typical client call getOperand on your helper when it wraps a 10,000 element ConstantAggregateZero? With CAZ the client is force to think about this case, and often handles it much much more efficiently. CAZ is a time optimization as well as a space optimization. -Chris On Jan 21, 2012, at 12:03 AM, Stepan Dyatkovskiy <STPWORLD at narod.ru> wrote: > Hi Chris.

Hi Chris. There is no zero arrays created. Probably this patch is not optimal and I'll reworked it today. But the main idea is keep a single zero-item when ConstantAggregateZero was wrapped and return this zero item as result of getOperand call. Note that wrapper has no parent classes, it has very local and short lifetime (method body), it exists outside the LLVMContext and needed for

Hm... tests were corrected themselves. No svn updates was made. 0. I turned on my laptop and boot Ubuntu 11.04. 1. I run ../llvm/configure in clean folder. 2. make 3. make check-lit 4. Tests was looped at 61%. Eclipse doesn't want to debug it too. It crashes at the start of debug session. I reboot my computer again, and all work well now. Probably some specific bios + OS + (specific cpu

ping. -Stepan. Stepan Dyatkovskiy wrote: > Hi, > > Please find the attached patch for review. > > -Stepan. > > John McCall wrote: >> On Oct 28, 2011, at 2:00 AM, Stepan Dyatkovskiy wrote: >>> I found next code when switch instruction differs: >>> >>> Engine.logf("right switch has extra case %r")<< CaseValue; >>>

Yep check out PR1324. Doing something like this would be a great improvement. -Chris On Jan 21, 2012, at 9:42 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Anton, in a solution without CAZ, isNullValue can just return true when it > sees the special "this ConstantArray is all zero" flag. So all the places that > now look for CAZ can just use isNullValue instead

Hi Stepan, This looks interesting! Some high-level comments: - Please post the patch untarred next time. Also, I'm not sure if it's typical to provide supporting documents in .doc format; while many of us probably have access to Word, a more portable and email-friendly format (like text, markdown or rst) is probably better. - Have you profiled this? What's the speedup? I

Hi! currently instcombine does not detect constant diagonal matrix times vector, for example a.xx * [2 0] + a.yy * [0 3] can be optimized to a * [2 3] I have implemented this for float. I know that this assumes x * 0 = 0 which is not ieee compliant but i post it here in case it is interesting for someone. on my wish list there is still an option for target independent optimizations to have x