similar to: Help handling opaque AArch64 immediates

The attached patch adds a construct that enables extending the base class' lists rather than completely overwriting them. The patch hasn't gone through extensive testing yet (other than running make check). The lists can be extended either with a "+=" operator in a let statement or placing a '"+" in front of a superclass: - Example 1: def D0 : C1 { let

If you are changing the syntax, please update the BNF in the comments. --Sean Silva On Wed, Sep 12, 2012 at 6:16 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > The attached patch adds a construct that enables extending the base class' > lists rather than completely overwriting them. > The patch hasn't gone through extensive testing yet (other than running make >

Please take a look at the attached patch. I updated the BNF and added comments in the code. On Wed, Sep 12, 2012 at 4:58 PM, Sean Silva <silvas at purdue.edu> wrote: > If you are changing the syntax, please update the BNF in the comments. > > --Sean Silva > > On Wed, Sep 12, 2012 at 6:16 PM, Akira Hatanaka <ahatanak at gmail.com> > wrote: > > The attached

Hi, For the following code: void foo (); int main () {foo();} llvm emits "bl foo" Then I set foo at a far address in linking: aarch64-linux-gnu-gcc -Wl,--defsym=foo=0x80000000 a.o -o a.exe I got an error from ld: a.c:(.text+0x8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `foo' define in *ABS* section in a.exe The question is: do I

Hi, I'm trying to understand how virtual regs are assigned to operands in IR instructions. I looked into SelectionDAG but could not figure out where the assignment happens. How and where does this conversion happen? Furthermore, I want to build a map between variable and the virtual register (x corresponds to vreg11 in below code). I've been stuck here for a while. Any help is greatly

On 25 November 2014 at 10:18, Jonathan Lennox <jonathan at vidyo.com> wrote: > > On Nov 25, 2014, at 11:13 AM, Viswanath Puttagunta > <viswanath.puttagunta at linaro.org> wrote: > > On 25 November 2014 at 10:11, Viswanath Puttagunta > <viswanath.puttagunta at linaro.org> wrote: > > > On 25 November 2014 at 09:39, Jonathan Lennox <jonathan at

Hello, I am developing GlobalISel for MIPS. I have a few questions and observations about defining legality of generic instruction and also possible combining of instructions and artifacts in pre/post legalizer combiner or elsewhere (e.g. in some sort of instruction-select patterns). I look at legality as "If generic instruction can be selected into machine instruction, it is legal".

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

On Nov 25, 2014, at 11:13 AM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org<mailto:viswanath.puttagunta at linaro.org>> wrote: On 25 November 2014 at 10:11, Viswanath Puttagunta <viswanath.puttagunta at linaro.org<mailto:viswanath.puttagunta at linaro.org>> wrote: On 25 November 2014 at 09:39, Jonathan Lennox <jonathan at vidyo.com<mailto:jonathan at

On 25 November 2014 at 10:11, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > > On 25 November 2014 at 09:39, Jonathan Lennox <jonathan at vidyo.com> wrote: > > > > On Nov 25, 2014, at 10:07 AM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > >> > >> > Also is there plans to make the NEON optimisations

Hi, All: I have a testcase which produced incorrect result, it's caused by the combination of nsw flag and ExtLdPromotion, I am leaning to say Clang set nsw flag incorrectly, but please let me know if I was wrong. Here is the reduced testcase: long long foo(int *a) { long long c; c = *a * 1405; return c; } Clang emitted the following IR (It is done by EmitMUL() in

On 30 January 2015 at 02:41, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Zhongwei Yao wrote: >> Hi, all, >> >> Does Opus need celt_pitch_xcorr? s fixed point version for ARM aarch64 >> architecture? If yes, which version does Opus prefer: assembly or >> instrinsics? > > It would be nice to have one. I don't have a lot of experience with

Speaking of conversion, do we actually have Neon code for int<->float conversion? Jean-Marc On 01/02/15 05:26 PM, Timothy B. Terriberry wrote: > Viswanath Puttagunta wrote: >> Could you please elaborate on "It would be nice to have"? Specifically: >> - Are there use cases where fixed point is preferred when AAarch64 has >> mandatory support for floating

v2 -> v3 - Don't make a special case for WdfCoInstaller* files. There is a difference of opinion about whether copying these is necessary, but it seems like it is not harmful. Rich.

I think one - maybe final? - problem. How can I tell the difference between drivers for "client" versions of Windows (eg. Windows 7) and server versions of Windows (eg. Windows 2008 Server)? It seems in many or most cases the drivers are identical, eg: $ md5sum viostor/2k12/amd64/* viostor/w8/amd64/* bbe250c13bf891fd7292ccab9908a63a viostor/2k12/amd64/viostor.cat

Since v1: - Fix a bug in the calculation of lc_basename. By luck this doesn't affect anything given the contents of the current ISO. - Don't copy the WdfCoInstaller*.dll files. Rich.

https://github.com/rwmjones/libguestfs/tree/rewrite-virtio-copy-drivers Instead of trying to split and parse elements from virtio-win paths, use the '*.inf' files supplied with the drivers to control how Windows drivers are installed. The following emails best explain how this works: https://www.redhat.com/archives/libguestfs/2015-October/msg00352.html

Viswanath Puttagunta wrote: > Could you please elaborate on "It would be nice to have"? Specifically: > - Are there use cases where fixed point is preferred when AAarch64 has > mandatory support for floating point both in regular CPU as well as > NEON? Even on x86, when the complexity setting is below the maximum, then for medium-low bitrate speech the fixed-point encoder

On 25 November 2014 at 09:39, Jonathan Lennox <jonathan at vidyo.com> wrote: > > On Nov 25, 2014, at 10:07 AM, Viswanath Puttagunta < viswanath.puttagunta at linaro.org> wrote: >> >> > Also is there plans to make the NEON optimisations on ARMv7 run time >> > detectable like they have in cairo/pixman? For generic distributions >> > it would nice to

Patch 1 moves the v2v/fake-virtio-win and v2v/fake-virt-tools directories to the recently created test-data/ hierarchy. This is just refactoring with no functional change at all. Patches 2-4 then extend the available (fake) virtio-win drivers: - Patch 2 adds all of the drivers from the virtio-win RPM. - Patch 3 adds all of the drivers from the virtio-win ISO (which are different from the