search for: uncombines

On Wed, Feb 18, 2009 at 10:14 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I'm still trying to track down some alignment issues with loads(i.e. 8/16 > bit loads being turned into 32bit sign extending loads) and I cannot for the > life of me seem to figure out how to enter this section of code: > > // If this is an unaligned load and the target doesn't support

I'm still trying to track down some alignment issues with loads(i.e. 8/16 bit loads being turned into 32bit sign extending loads) and I cannot for the life of me seem to figure out how to enter this section of code: // If this is an unaligned load and the target doesn't support it, // expand it. if (!TLI.allowsUnalignedMemoryAccesses()) { unsigned

...t expects it to be a certain form, but my custom load instruction has a different form. Setting it to Legal generates the sext_load in the first dag combine pass, because it never checks if it should make this combination. Since it doesn't enter the section of code I mentioned earlier, it never uncombines it. When I set it to promote, it asserts on "not yet implemented". Setting it to Expand does not expand it to sign_extend and load but to extload and sign_extend, but I don't support extload either. Please correct me if I am wrong, but I've been looking at this issue for awhile...

On Wed, Apr 18, 2012 at 12:22 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > I tried disabling just the InstCombine transforms that hide shl > instructions behind bitmasks. Even though DAGCombine has the same > transforms, it causes some pretty bad regressions: > I wonder about your idea of still combining most of the shifts, but leaving the last bits uncombined...

On Apr 16, 2012, at 3:30 PM, Chandler Carruth <chandlerc at google.com> wrote: > Does sinking these into the DAGCombine layer help? How much does it break? I tried disabling just the InstCombine transforms that hide shl instructions behind bitmasks. Even though DAGCombine has the same transforms, it causes some pretty bad regressions: External/SPEC/CINT95/147_vortex/147_vortex

Hi Gabrielle, > > Historically nodes marked "custom" were considered legal, so the > > DAGCombiner would have been correct to generate it. Not sure how > > that ever worked though. I think Dan split the isOperationLegal > > method into isOperationLegal and isOperationLegalOrCustom for reasons > > related to this kind of thing. I don't know whether

> Historically nodes marked "custom" were considered legal, so the > DAGCombiner would have been correct to generate it. Not sure how > that ever worked though. I think Dan split the isOperationLegal > method into isOperationLegal and isOperationLegalOrCustom for reasons > related to this kind of thing. I don't know whether the DAGCombiner > is now only supposed

ocaml-augeas is used only by virtlibguestfs, so move it to this repository, instead of having it around in the common submodule. The removal from common will happen later. Pino Toscano (2): Bundle the ocaml-augeas library for use by libguestfs build: switch embedded copy of ocaml-augeas .gitignore | 1 + 3rdparty/ocaml-augeas/COPYING.LIB | 515

depends on "autoconf: regenerate configure scripts with 4.4 version" This series removes some of the really old deadwood from the tools build and makes some other things which are on their way out configurable at build time with a default depending on how far down the slope I judge them to be. * nuke in tree copy of libaio * nuke obsolete tools: xsview, miniterm, lomount & sv *