Displaying 6 results from an estimated 6 matches for "isextend".
Did you mean:
extend
2009 Feb 07
1
[LLVMdev] Patch: More data types
...d all the items that are hard coded to 32 and a section that isn't,
but I cannot figure out how to expand it so that there can be up to 64
data types.
The section in question is TargetLowering.h and seems to be these two
functions.
LegalizeAction getTypeAction(MVT VT) const {
if (VT.isExtended()) {
if (VT.isVector()) return Expand;
if (VT.isInteger())
// First promote to a power-of-two size, then expand if
necessary.
return VT == VT.getRoundIntegerType() ? Expand : Promote;
assert(0 && "Unsupported extended type!");...
2010 Apr 21
1
[LLVMdev] Bufer overrun in getValueTypeList()
...ere is a discrepancy between the size of the array VTs and the use in getTypeValueList(). The array is allocated with space for elements up to LAST_VALUE_TYPE and iPTR is defined after it. The enumerator value of iPTR is between LAST_VALUE_TYPE and LastSimpleValueType. For this reason the check VT.isExtended() fails and the value is looked up in VTs triggering an out of bounds access. In the version of LLVM we're using getValueTypeList even tries to write to that array element causing a memory corruption. Should iPTR handled with the extended types, simple types or in a different way? Should thi...
2012 Apr 19
0
[LLVMdev] Target Dependent Hexagon Packetizer patch
...;> #include "llvm/ADT/SmallVector.h"
>> #include "llvm/CodeGen/DFAPacketizer.h"
>> @@ -466,7 +466,862 @@ unsigned HexagonInstrInfo::createVR(MachineFunction* MF, MVT VT) const {
>> return NewReg;
>> }
>>
>> +bool HexagonInstrInfo::isExtendable(const MachineInstr *MI) const {
>> + switch(MI->getOpcode()) {
>> + // JMP_EQri
>> + case Hexagon::JMP_EQriPt_nv_V4:
>> + case Hexagon::JMP_EQriPnt_nv_V4:
>> + case Hexagon::JMP_EQriNotPt_nv_V4:
>> + case Hexagon::JMP_EQriNotPnt_nv_V4:
>...
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
> Can you explain why you chose the approach of using a new pass?
> I pictured removing LegalizeDAG's type legalization code would
> mostly consist of finding all the places that use TLI.getTypeAction
> and just deleting code for handling its Expand and Promote. Are you
> anticipating something more
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 1:34 PM, Eli Friedman wrote:
> On Wed, May 20, 2009 at 1:19 PM, Eli Friedman
> <eli.friedman at gmail.com> wrote:
>
>> Per subject, this patch adding an additional pass to handle vector
>>
>> operations; the idea is that this allows removing the code from
>>
>> LegalizeDAG that handles illegal types, which should be a significant
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...rand(i).getValueType())) {
- case Legal:
- NewValues.push_back(LegalizeOp(Node->getOperand(i)));
- NewValues.push_back(Node->getOperand(i+1));
- break;
- case Expand: {
- SDValue Lo, Hi;
- assert(!Node->getOperand(i).getValueType().isExtended() &&
- "FIXME: TODO: implement returning non-legal vector types!");
- ExpandOp(Node->getOperand(i), Lo, Hi);
- NewValues.push_back(Lo);
- NewValues.push_back(Node->getOperand(i+1));
- if (Hi.getNode()) {
- NewV...