similar to: [LLVMdev] How to force the creation of arrays with zeroes?

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 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

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.

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 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

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

> you can't, you can only get a ConstantAggregateZero.  This is actually kind of > annoying, and means that places expecting a ConstantArray have to remember to > also check for ConstantAggregateZero.  Perhaps there's a good reason for the > current design, but if not it would be great to eliminate this wart. Well, I think the main reason it so reduce the size of .ll / .bc when

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

Hi Anton, >> you can't, you can only get a ConstantAggregateZero. This is actually kind of >> annoying, and means that places expecting a ConstantArray have to remember to >> also check for ConstantAggregateZero. Perhaps there's a good reason for the >> current design, but if not it would be great to eliminate this wart. > Well, I think the main reason it so

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

Sorry, forgot to reply-all ---------- Forwarded message ---------- From: Anton Korobeynikov <anton at korobeynikov.info> Date: Sat, Jan 21, 2012 at 20:59 Subject: Re: [LLVMdev] How to force the creation of arrays with zeroes? To: Stepan Dyatkovskiy <STPWORLD at narod.ru> > Though, there is also cases when we really need to transform it to 10,000 zeroes (just look at CBackend.cpp,

Hi Stepan, > Hi all. How to force the creation of arrays with zeroes? Or this use-case is not provided? you can't, you can only get a ConstantAggregateZero. This is actually kind of annoying, and means that places expecting a ConstantArray have to remember to also check for ConstantAggregateZero. Perhaps there's a good reason for the current design, but if not it would be great to

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

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

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"

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

Guys, you can exclude me (dyatkovskiy) from this list, since I reverted my changes in r162354. -Stepan. llvm.buildmaster at lab.llvm.org wrote: > The Buildbot has detected a new failure on builder clang-native-mingw64-win7 while building cfe. > Full details are available at: > http://lab.llvm.org:8011/builders/clang-native-mingw64-win7/builds/876 > > Buildbot URL:

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

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

Hi all, Previous patch has been split onto series of small changes. On each stage (after each patch) MergeFunctions pass is compilable and stable. Please find patches in attachment for review. To apply all patches at once, use "apply-patches.sh" script as follows: 0. Place "apply-patches.sh" in same directory with patches. 1. cd <llvm-sources-dir> 2. "bash