Displaying 5 results from an estimated 5 matches for "x86xop".
Did you mean:
x86jmp
2016 Mar 29
2
UBSan, StringRef and Allocator.h
...bug in the SelectionDAG tablegen matcher this has uncovered. Seems that ComplexPattern’s don’t track MemRefs. It probably (hopefully!) just causes downstream code to be conservative but its possible there’s real issues being hidden by this.
The problematic code is something like ‘xop(load) -> X86XOPrm’ where the resulting X86XOP MachineInstr wouldn’t have an MachineMemOperand’s, despite being marked as loading from memory.
Will file a PR so that we can track some of these issues.
Pete
>>
>> That said, I don't think we can be terribly cavalier with what we expect from standar...
2016 Mar 29
0
UBSan, StringRef and Allocator.h
...legen matcher this has uncovered. Seems that ComplexPattern’s
> don’t track MemRefs. It probably (hopefully!) just causes downstream
> code to be conservative but its possible there’s real issues being
> hidden by this.
>
> The problematic code is something like ‘xop(load) -> X86XOPrm’ where
> the resulting X86XOP MachineInstr wouldn’t have an
> MachineMemOperand’s, despite being marked as loading from memory.
>
> Will file a PR so that we can track some of these issues.
Coming late to this discussion since I just noticed this was talking
about MemRefs...
We ha...
2016 Mar 30
1
UBSan, StringRef and Allocator.h
...onDAG tablegen matcher this has uncovered. Seems that ComplexPattern’s don’t track MemRefs. It probably (hopefully!) just causes downstream code to be conservative but its possible there’s real issues being hidden by this.
>>
>> The problematic code is something like ‘xop(load) -> X86XOPrm’ where the resulting X86XOP MachineInstr wouldn’t have an MachineMemOperand’s, despite being marked as loading from memory.
>>
>> Will file a PR so that we can track some of these issues.
> Coming late to this discussion since I just noticed this was talking about MemRefs...
>...
2016 Mar 29
0
UBSan, StringRef and Allocator.h
> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero.
Yeah, I agree. I’ve tried running the tests with the assert in place and there’s about 1000 failures across llvm/clang. I’ll see what I can fix as I would like to get these to behave. There
2016 Mar 28
2
UBSan, StringRef and Allocator.h
FWIW, I agree with Mehdi that we should just assert that our types don't
get called with size zero.
That said, I don't think we can be terribly cavalier with what we expect
from standard allocator types, operator new, or malloc. And so I would
expect LLVM_ATTRIBUTE_RETURNS_NOALIAS to not imply NONNULL, and while it
seems reasonable to put NONNULL on *our* allocate function because of the