search for: reorg

...s. This is stuff that will be shared by SSE, MMX and AVX patterns. Eventually, they will all converge under one framework but in the meantime we need to do some code sharing so I want to move the common stuff into a single file. Assuming this patch looks ok, I'll commit it and commit similar reorg patches as I generate them. They will all be in the same spirit, no code changes, just shuffling stuff around. Comments? -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: simdfragments.patch Type: text/x-diff Size: 6386 bytes De...

Now that Bruno is putting in some AVX stuff, it's a good motivator to move my x86 SIMD reorg work into trunk (and got management to agree to prioritize it - Thanks Bruno! :) ). Attached is the first patch of many to accomplish this. The overall goal is to have all x86 SIMD instructions share a set of common patterns so that we can have a more maintainable machine description (e.g. SS, SD...

...tablegen patches > you commited, there's a great chance the sse/avx code would become unreadable, > I think this is harder to maintain and improve. Of course we will discuss things as we go. Since you've done a good deal of AVX implementation already, we can think of my patches as a reorg to consolidate the pattern space. This will hopefully become clearer as I sned stuff for comment. I also have some blog posts ready to go. -Dave

Hi David, On Fri, Jul 9, 2010 at 3:25 PM, David Greene <dag at cray.com> wrote: > Now that Bruno is putting in some AVX stuff, it's a good motivator to > move my x86 SIMD reorg work into trunk (and got management to agree to > prioritize it - Thanks Bruno! :) ). > > Attached is the first patch of many to accomplish this.  The overall > goal is to have all x86 SIMD instructions share a set of common patterns > so that we can have a more maintainable machine...

On Jul 12, 2010, at 11:45 AM, David A. Greene wrote: > > I don't see how this patch could cause any failures. > > Is somethinmg tricky going on with the Frontend* tests at the moment? I just updated and ran everything and it's working fine for me. (Note that I haven't tested with your patch.) -eric

This is a medium-ish article I wrote up about the current state of the x86 SSE .td files (sans Bruno's ongoing work on AVX). While some of the code snippets are a little bit out-of-date (owing to said work by Bruno and others), the basic concepts still apply. Essentially, the article outlines several places in the current .td files that have redundancy and how that redundancy has led to some

I've moved our source repository into the top-level svn.xiph.org tree. After using the new set up for a bit, I think having everything (but icecast) in one tree makes more sense. If you have a check out from the old location you can migrate your working copy: cd <theora-working-directory> svn switch http://svn.xiph.org/trunk/theora or svn switch

...atches will provide everything I need. If my evil plan works out, within the next 10 or so patches we should be in a place where pushing everything up goes pretty quickly. It's about 8 TableGen patches and then a patch to do ADD or some other simple thing like that to start the so-called SIMD reorg. Basically, if I can get the SIMD reorg patch settled, everything after that is really simple because it all looks uniform. Of course, that reorg/ADD patch is going to cause a lot of discussion, I suspect. ;) >>> There seems to be some code for this because >>> xor<8 x i32&...

Hi David, >> The last time the AVX backend was mentioned on this list seems to be >> from November 2010, so I would like to ask about the current status. Is >> anybody (e.g. at Cray?) still actively working on it? > > Yes, we are! I am doing a lot of tuning work at the moment. We have > been rather swamped with work for new products and I am now just getting > out

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: >> This patch merely moves some common pattern fragments (memop, >> alignedload, etc.) to a file separate from X86InstrSSE.td so that all >> current x86 SIMD implementations can still use the classes while the >> transition happens. >> >> Ok to commit? > > I'm Ok with this patch. So

I have a system with 4 disk drives, two 512 Gb and two 1 Tb. It look like this: CentOS release 5.9 (Final) Disk /dev/sda: 500.1 GB, 500107862016 bytes Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes Disk /dev/sdc: 500.1 GB, 500107862016 bytes Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes ================================================================= Disk /dev/sda: 500.1 GB, 500107862016 bytes

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: > Hi Ralf > > On Wednesday, June 1, 2011, Ralf Karrenberg <Chareos at gmx.de> wrote: >> Hi, >> >> The last time the AVX backend was mentioned on this list seems to be >> from November 2010, so I would like to ask about the current status. Is >> anybody (e.g. at Cray?) still actively working

This is a heads up - if you aren't into ELF or ARM, you can stop reading :-) I need to add ARM specific relocation support which require some amount of reorg to the exiting ELFObjectWriter.* to remove x86 biases (or at least move them elsewhere). I am currently working on a set of patches, which I will send to commits for review, hopefully in a day or three. Thanks -jason

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly outpu...

I've installed new complete-page versions of the vorbis spec on the website: http://www.xiph.org/ogg/vorbis/doc/ the per-section html versions have not yet been updated. I also updated docbook, xsltproc, and tetex on motherfish, and installed a catalog file in /etc/xml/catalog since the docbook stuff is a little hard to get going. The docs should build out of the box there now

...ol. A bunch of stuff seems to be in headers just because of technicalities. virtio common seems to be a dumping ground with no guiding principle at all. drivers/net/virtio/virtnet_virtio.c is weird with virt repeated three times in the path. These things only get murkier with time, at the point of reorg I would expect very logical placement, since without clear guiding rule finding where something is becomes harder but more importantly we'll now get endless heartburn about where does each new function go. The reorg is unfortunately not free - for example git log --follow will no longer easil...

...ping > group. This is something we should pay attention to after this. > > > > drivers/net/virtio/virtnet_virtio.c is weird with > > virt repeated three times in the path. > > Any good idea. > > > > > These things only get murkier with time, at the point of reorg > > I would expect very logical placement, since > > without clear guiding rule finding where something is becomes harder but > > more importantly we'll now get endless heartburn about where does each new > > function go. > > > > > > The reorg is unfort...

...pay attention to after this. > > > > > > > drivers/net/virtio/virtnet_virtio.c is weird with > > > virt repeated three times in the path. > > > > Any good idea. > > > > > > > > These things only get murkier with time, at the point of reorg > > > I would expect very logical placement, since > > > without clear guiding rule finding where something is becomes harder but > > > more importantly we'll now get endless heartburn about where does each new > > > function go. > > > > > >...

...Flag_NTPOFF: > O << "@NTPOFF"; > break; > > > etc. The possible set of suffixes and modifiers are all target- > specific, so the main code generator would just pass them through (as > it does now). > > Does anyone have any objections to this? Can you reorg MachineOperand fields while you are at it? :-) Right now each MachineOperand uses 8 bits for type, followed by 5 bits for various flags, then a whole 8-bit for subreg. If we use just 3-bit for subreg (should be enough?), the target independent part will just take up 16-bits and leave plent...

On Nov 9, 2010, at 9:31 AM, Jason Kim wrote: > This is a heads up - if you aren't into ELF or ARM, you can stop reading :-) > > I need to add ARM specific relocation support which require some > amount of reorg to the exiting ELFObjectWriter.* to remove x86 biases > (or at least move them elsewhere). > I am currently working on a set of patches, which I will send to > commits for review, hopefully in a day or three. Thanks for the heads up, Jason. Looking forward to seeing the patches! -Jim