Displaying 20 results from an estimated 439 matches for "disambiguate".
2013 Jul 11
1
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote:
> http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/
> asm/bitops.h#L68
>
> Here is one example that I found. Are the inline assembly arguments
> ambiguous in size?
It would help us for sure to build the kernel and others.
--
JS
2013 Jul 10
3
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
...(+)
>
> diff --git a/lib/Target/X86/X86InstrInfo.td b/lib/Target/X86/X86InstrInfo.td
> index f33ae2a..4950674 100644
> --- a/lib/Target/X86/X86InstrInfo.td
> +++ b/lib/Target/X86/X86InstrInfo.td
> @@ -1971,6 +1971,10 @@ def : InstAlias<"aam", (AAM8i8 10)>;
> // Disambiguate the mem/imm form of bt-without-a-suffix as btl.
> def : InstAlias<"bt $imm, $mem", (BT32mi8 i32mem:$mem, i32i8imm:$imm)>;
>
> +// Disambiguate btr and bts, just like GNU as.
> +def : InstAlias<"btr $imm, $mem", (BT16mi8 i16mem:$mem, i16i8imm:$imm)>;
>...
2009 Feb 18
4
Disambiguate List Item Followed by Code Block
Howdy,
Quick question: Since list items with multiple paragraphs need to be
indented four spaces, and code blocks are also indented four spaces,
is there any way to disambiguate a list followed by a code block?
Example:
* This is a list
item.
* And so is this.
Is this a second paragraph in the second list item,
or a code block?
It looks like Markdown.pl and discount agree that it should be a
second paragraph. If that is indeed the standard, what s...
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
...--git a/lib/Target/X86/X86InstrInfo.td b/lib/Target/X86/X86InstrInfo.td
>> index f33ae2a..4950674 100644
>> --- a/lib/Target/X86/X86InstrInfo.td
>> +++ b/lib/Target/X86/X86InstrInfo.td
>> @@ -1971,6 +1971,10 @@ def : InstAlias<"aam", (AAM8i8 10)>;
>> // Disambiguate the mem/imm form of bt-without-a-suffix as btl.
>> def : InstAlias<"bt $imm, $mem", (BT32mi8 i32mem:$mem, i32i8imm:$imm)>;
>>
>> +// Disambiguate btr and bts, just like GNU as.
>> +def : InstAlias<"btr $imm, $mem", (BT16mi8 i16mem:$mem, i16i8imm...
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
.../cd/E19253-01/817-5477/817-5477.pdf
I'm not sure I'd use the documentation for the Solaris assembler as authoritative for AT&T syntax, but page 17 does say that if the suffix is omitted it defaults to long.
However, that isn't my experience with gas which uses register operands to disambiguate, if possible (although I'm on a phone and can't check right now).
--
Stephen Checkoway
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/30d207c7/attachment.html>
2020 Jul 07
3
BUILD_VECTOR disambiguation
Thanks for the clarification. The `except` seemed dangling to me, but
it's early here.
Just curious... how do we end up with a mixed type BUILD_VECTOR?
That's counterintuitive.
On Tue, Jul 7, 2020 at 10:58 AM Krzysztof Parzyszek via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Mixed integer types are ok, but the values will get truncated to the element type of the output
2020 Jul 07
2
BUILD_VECTOR disambiguation
Mixed types aren't allowed. They are checked for in VerifySDNode in
SelectionDAG.cpp and will fail an asserts build.
~Craig
On Tue, Jul 7, 2020 at 8:25 AM Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> The problem can happen when you want to build a vector of i8, but i8
> itself is not legal on your target. All operands to BUILD_VECTOR will be
>
2007 Mar 21
0
[909] branches/wxruby2/wxwidgets_282/doc/textile/combobox.txtl: Correct disambiguated method names in methods listing
...round:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<title>[909] branches/wxruby2/wxwidgets_282/doc/textile/combobox.txtl: Correct disambiguated method names in methods listing</title>
</head>
<body>
<div id="msg">
<dl>
<dt>Revision</dt> <dd>909</dd>
<dt>Author</dt> <dd>brokentoy</dd>
<dt>Date</dt> <dd>2007-03-21 06:54:07 -0400 (Wed,...
2020 Jul 07
3
BUILD_VECTOR disambiguation
Hey devs,
>From ISDOpcodes.h...
/// BUILD_VECTOR(ELT0, ELT1, ELT2, ELT3,...) - Return a fixed-width vector
/// with the specified, possibly variable, elements. The number of elements
/// is required to be a power of two. The types of the operands must all be
/// the same and must match the vector element type, except that integer types
/// are allowed to be larger than the element type, in
2013 Jul 11
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
...if the suffix is omitted it defaults to long.
Yeah, me either. That’s part of why I’m asking for references. I’d love to know which ones other people use. Good docs for AT&T syntax are annoyingly hard to find.
> However, that isn't my experience with gas which uses register operands to disambiguate, if possible (although I'm on a phone and can't check right now).
Yep, it’s the memory reference versions which IIUC require a suffix.
I want to make sure we do the right thing here and know why we’re doing it rather than just adding some aliases because it matches gas’ behavior.
-Jim
--...
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
...lts to long.
>
>
> Yeah, me either. That’s part of why I’m asking for references. I’d love to
> know which ones other people use. Good docs for AT&T syntax are annoyingly
> hard to find.
>
> However, that isn't my experience with gas which uses register operands to
> disambiguate, if possible (although I'm on a phone and can't check right
> now).
>
>
> Yep, it’s the memory reference versions which IIUC require a suffix.
>
> I want to make sure we do the right thing here and know why we’re doing it
> rather than just adding some aliases because i...
2005 Oct 06
8
accessing extra request parameters
hi all,
how are other people passing and accessing ''get'' parameters from their apps?
what is the best way to do it?
ie:
www.example.com/controller/action/id/extra/extra2/ ??
or
www.example.com/controller/action/id/~extra/extra2/
or what ever....
are there built in methods for passing and accessing extra parameters?
thanks for your suggestions
-felix
2013 Oct 11
0
[LLVMdev] Request for comments: TBAA on call
On Thu, Oct 10, 2013 at 9:34 PM, Chris Lattner <clattner at apple.com> wrote:
> On Oct 10, 2013, at 8:53 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
> The datastructures and algorithms we have are powerful enough to express
>> these sorts of things, and so long as a frontend abided by the rules, there
>> shouldn't be a problem.
>>
>
>
>
2013 Jul 10
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> Also, please elaborate on why this is a good change. Because gas accepts it
> isn’t sufficient reason in and of itself.
That they're valid instructions isn't sufficient reason? Should I
additionally say that linux.git uses them?
I wrote:
> The instructions btr and bts are perfectly valid, and have existed since
> Intel 386.
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> Jim Grosbach wrote:
>> Also, please elaborate on why this is a good change. Because gas accepts it
>> isn’t sufficient reason in and of itself.
>
> That they're valid instructions isn't sufficient reason? Should I
> additionally say that linux.git uses them?
>
Is the
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> That does raise a clarifying question here. Is the code you’re interested in
> using Intel or AT&T syntax?
>
> Also note that the question isn’t whether we should support the btr/bts
> instructions. We absolutely must (and do). The question is whether we are
> properly handling the un-suffixed mnemonic form of the assembly syntax.
>
> Perhaps you
2013 Jul 17
0
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> Jim Grosbach wrote:
> > No. The above rule is absolutely the wrong thing to do, as has been
> > previously noted.
>
> I don't give a shit about whether you think it is "absolutely wrong"
> or not; I did what hpa and the Intel manual outlined. If you have
> some _reason_ not to do
2013 Jul 17
1
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Jul 17, 2013 7:41 AM, "Joerg Sonnenberger" <joerg at britannica.bec.de>
wrote:
>
> On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> > Jim Grosbach wrote:
> > > No. The above rule is absolutely the wrong thing to do, as has been
> > > previously noted.
> >
> > I don't give a shit about whether you think it is
2004 Apr 05
2
Disambiguating incoming IAXTel calls
I have two 1-700 numbers from IAXTel. Both get registered from the same
Asterisk server. I can make and receive calls on each without any
difficulty. What I can't figure out how to do is route the incoming calls
differently based on which 1-700 number is dialed. I must be missing
something obvious.
Thanks
-brian
-------------- next part --------------
An HTML attachment was scrubbed...
2014 May 13
2
[LLVMdev] Instructions with overlapping encodings that are disambiguated by field comparisons
Hi,
I'm not sure how to handle some of the trickier instruction encodings in MIPS64r6. My problem is that some instructions determine the operation based on the relationship between two fields. For example, 'beqc $rs, $rt, offset' (branch if equal, no delay slot) and bovc (branch if addition would overflow, no delay slot) share the same major opcode and field layout. When the register