Displaying 7 results from an estimated 7 matches for "_have_to_".
Did you mean:
_has_to_
2011 Mar 17
2
[LLVMdev] Long-Term ISel Design
...; Yes, this isn't good. Instead, the shuffle should be legalized to
> something that takes a pointer (memory operand). That means that X86
> isel would form the *fully legal* X86ISD node, and nothing would be
> able to break it and it could never fail to match.
Well, it dopesn't _have_to_ form an X86ISD node. I don't do that now.
But it's fragile in the sense that no one else should mess with that
piece of the DAG.
But the real point is that in forming the X86ISD node currently, I'm
doing exaclty what the tblgen-generated code already does. If the
shuffle doesn't...
2011 Mar 18
0
[LLVMdev] Long-Term ISel Design
...good. Instead, the shuffle should be legalized to
>> something that takes a pointer (memory operand). That means that X86
>> isel would form the *fully legal* X86ISD node, and nothing would be
>> able to break it and it could never fail to match.
>
> Well, it dopesn't _have_to_ form an X86ISD node. I don't do that now.
> But it's fragile in the sense that no one else should mess with that
> piece of the DAG.
I don't consider that an acceptable approach. There is no way to prevent something from CSE'ing a load away and "breaking" the dag,...
2002 Jul 11
1
mp3 quality vs Vorbis 1.0?
Many of you have read and my "introduction to compressed audio with Vorbis"
and given me excellent feedback. But with 1.0 about to hit the streets, I
figured I'd freshen it up a bit.
[ http://grahammitchell.net/writings/vorbis_intro.html ]
In particular, it contains two paragraphs discussing the relative quality of
Vorbis vs mp3 at a certain target bitrate. These figures seem
2011 Mar 17
0
[LLVMdev] Long-Term ISel Design
On Mar 16, 2011, at 1:44 PM, David Greene wrote:
> All,
>
> As I've done more integrating of AVX work upstream and more tuning here,
> I've run across several things which are clunky in the current isel
> design. A couple examples I can remember offhand:
>
> 1. We have special target-specific operators for certain shuffles in X86,
> such as X86unpckl. I
2011 Mar 16
3
[LLVMdev] Long-Term ISel Design
All,
As I've done more integrating of AVX work upstream and more tuning here,
I've run across several things which are clunky in the current isel
design. A couple examples I can remember offhand:
1. We have special target-specific operators for certain shuffles in X86,
such as X86unpckl. I don't completely understand why but Bruno
indicated it was to address inefficiecies.
2011 Mar 27
2
[LLVMdev] Long-Term ISel Design
...by definition it's not legal and we have to manually
lower it somehow, just like today. The only difference is that we do
it after (or in conjunction with) isel instead of before it. This will
eliminate a lot of confusing and redundant code in X86ISelLowering.
>> Well, it dopesn't _have_to_ form an X86ISD node. I don't do that now.
>> But it's fragile in the sense that no one else should mess with that
>> piece of the DAG.
> I don't consider that an acceptable approach. There is no way to
> prevent something from CSE'ing a load away and "break...
2005 Nov 02
6
firewall dilemma
Hi everyone,
I have this problem that I'm not sure what's the best solution for it. I
need your input & help...
I have an internal network behind a hardware firewall. All traffics go
thru. the firewall. One of the firewall's rules is that it doesn't allow
internal network accesses internal resources that travels outside then
come back. In the other words, it drops all