search for: mvts

dear all, we need help for integration asterisk (sip) with mera we have configure for sip.conf and extentions.conf sip.conf [mvts] context=mvts type=friend host=10.10.0.2 dtmf=rfc2833 in extentions.conf [mvts] ; ; mvts exten => _01162.,1,SetCallerID(mvts) exten => _01162.,2,SetCIDName(to mvts) exten => _01162.,3,Dial(SIP/${EXTEN:3}@mvts) i need if i dial 01162 in mera replace with 44522(interlocal call) but whe...

I'm having trouble to send calls to a Mera MVTS softswitch (with SIPHIT) when the asterisk box has a dynamic IP address. If the Asterisk box has a fixed IP, everything is OK. Any ideas? I'm looking for a working sample of the sip.conf in this case... user.cfg (for MVTS) is also appreciated if any special setting should be done there als...

...neration point of view because our immediate priority is llvm-mc support rather than auto-vectorisation. Can you please review the following text outlining MVT changes we would like to make so SVE instructions can be added to the AArch64 Target. My overriding question is whether you think the new MVTs are acceptable and in addition if you agree it makes sense to replicate the change to the IR's type system so that all vector MVTs are representable within the IR. I have two needs-to-be-updated patches for the IR type changes (https://reviews.llvm.org/D27101, https://reviews.llvm.org/D27102)...

...is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a > physical machine instruction and I typically want to think of those as > machine opcodes and machine register files. I am typically interested > in the mapping of MVTs to register classes when I'm generating machine > instructions. Note that a register class may map to multiple MVTs > depending on your description. Right, but the instruction opcode should give a clue about what the bits represent. That mapping is what's currently missing....

...information from a MachineOperand. Why do you need it for? In my mind, the MachineInstr and its associated operands represent a physical machine instruction and I typically want to think of those as machine opcodes and machine register files. I am typically interested in the mapping of MVTs to register classes when I'm generating machine instructions. Note that a register class may map to multiple MVTs depending on your description. -- Mon Ping On Sep 24, 2008, at 12:15 PM, Villmow, Micah wrote: > This only has the register class information, not the register type &gt...

...ypes (well, except for the ‘v3T’ types). The trend does seem to be towards larger bit-width SIMD registers, and as you say this will increase in time; but perhaps instead of using a discrete enumeration combined with additional entries in several switch-statements, it might be better to rethink MVTs using templates so that they can be instanced automatically as needed by a target. That might be one way of avoiding the problem of having either a sparse population of MVTs as needed by the sum of all in-tree targets, an on the other-hand the bloat of expressing all possible combinations. How...

This only has the register class information, not the register type information. My register class has multiple register types and I need to know how to differentiate which register type of my register class of the current register. The information in the MVT data type is what I need, i.e. the position in the GPRVT array of each register. Something equivalent to MVT getValueType() but for

...is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a > physical machine instruction and I typically want to think of those as > machine opcodes and machine register files. I am typically interested > in the mapping of MVTs to register classes when I'm generating machine > instructions. Note that a register class may map to multiple MVTs > depending on your description. Right, but the instruction opcode should give a clue about what the bits represent. That mapping is what's currently missing....

Hi All, I have a question about TableGen RegisterClass definition. I need to map different size of MVTs into a register class as below. def TestReg : RegisterClass<"Test", [v8i32, v4i32], ...> When I look at TableGen and CodeGen, it looks the types are used as following: 1. MCRegisterClass's RegSize and Alignment 2. SpillSize in TableGen 3. Type constraint for instruction patte...

Hi, Our backend for Pixel Visual Core uses some MVT's that aren't upstream. Does it make sense to upstream them? I figure that as architectures get wider, we'll eventually have "all" possible combinations of widths and types, but on the other hand having code that isn't used by current backends in tree isn't great. These are the MVT's that we have added: 16x16

...s(+), 78 deletions(-) commit 9add28389f360a0aa3f21b282a025c957309093f Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:59:05 2012 +0100 Change TargetLowering::getRepRegClassFor to take an MVT, instead of EVT. Accordingly, change RegDefIter to contain MVTs instead of EVTs. include/llvm/Target/TargetLowering.h | 5 ++--- lib/CodeGen/MachineLICM.cpp | 2 +- lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp | 16 ++++++++-------- lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp | 2 +- lib/CodeGen/SelectionDAG/ScheduleDAGSDNo...

...is that it is currently relatively hard to add new machine-specific register types. The only way of doing this involves extending MVT, which requires tweaking three files in the (nominally) target-independent parts of the compiler. It would be great if we could simply reserve a (small?) number of MVTs for target-specific legal values. David

...’ types). > > > > The trend does seem to be towards larger bit-width SIMD registers, and as > you say this will increase in time; but perhaps instead of using a discrete > enumeration combined with additional entries in several switch-statements, > it might be better to rethink MVTs using templates so that they can be > instanced automatically as needed by a target. That might be one way of > avoiding the problem of having either a sparse population of MVTs as needed > by the sum of all in-tree targets, an on the other-hand the bloat of > expressing all possible c...

> 1. copyRegToReg() won't be able to use register classes to pick a copy opcode. For instance, an XMM register will no longer be copied by MOVSS or MOVSD. Given just the physical register, MOVAPS will be used. Is that a problem? I haven't had time to really look into it, but have been playing around with the idea that instead of two register classes copyRegToReg and some of the load

...is that it is currently relatively hard to add new machine-specific register types. The only way of doing this involves extending MVT, which requires tweaking three files in the (nominally) target-independent parts of the compiler. It would be great if we could simply reserve a (small?) number of MVTs for target-specific legal values. I added MVT::Untyped a while back to address this kind of use case. You can construct node of MVT::Untyped, and as long as the InstrEmitter can infer what register class they can map to from their uses, everything should just work. Of course, it's only been...

Hello. I'm try to set up asterisk for making outgoing calls with oh323 channel driver version 0.7.1 with Asterisk CVS-1-01/09/05-01:41:37. Our provider uses Mera MVTS softswitch and supports only H.323. We don't use gatekeeper for connection but provider requires SOURCE PHONE NUMBER for route out calls and I don't know how I can specify this number. Call with this string exten => _XXXXXXX,1,Dial,OH323/${EXTEN}@mvts_ip_addr returns -- H.323 call ...

...ns, and it makes it clear that patterns operate on types, not register classes. This makes a huge amount of sense to me. Besides your motivating problem, writing an isel pattern that matches things in terms of register classes doesn't make *any* sense: the input graph has type labels that are MVTs. If you want to get *really* crazy, the ideal type system for dag nodes would be to allow either an EVT or a register class: after isel (and after some custom dag combines) the types of nodes should be register classes, since they are more specific than an MVT (or EVT). -Chris

...does seem wrong for a front-end to care about registers. I think I'll drop this crusade. > I must have missed that discussion, since I don't know what Ivan's problem > is. Essentially that pointers need to go in different registers to integers (and, presumably, all other valid MVTs). Thanks Duncan! Tim.

...on't matter). This is in the backend of LLVM itself. When converting the LLVM IR to its DAG representation prior to selection, CodeGen asks the target to take care of function parameters. Unfortunately the only interface it presents for the target code to make that decision is a sequence of MVTs: iN, float, double, vNiM, vNfM. Structs are split into their component members with no indication that they were originally more than that. This has affected a couple more people recently (including me): http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048203.html http://lists.cs.uiuc.edu/...

...have the same number of elements, and the same number of bytes if `Min * sizeof(type)` is the same: `<n x 4 x i32>` and `<n x 4 x i8>` have the same number of elements. `<n x 4 x i32>` and `<n x 8 x i16>` have the same number of bytes. ## SelectionDAG New scalable vector MVTs are added, one for each existing vector type. Scalable vector MVTs are modelled in the same way as the IR. Hence, `<n x 4 x i32>` becomes `nxv4i32`. ## MVT Interface: ```cpp static MVT getVectorVT(MVT VT, ElementCount EC); bool isScalableVector() const; static mvt_range integer_scalab...