Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] Casting between address spaces and address space semantics"
2008 Jul 17
0
[LLVMdev] Casting between address spaces and address space semantics
On Thu, Jul 17, 2008 at 5:08 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote:
> Now, we are using a function which reads a value from one of these memories
> and does some processing. Since we want to execute this function for multiple
> memories, we make it accept a pointer in the generic address space (ie, no
> address space attribute):
>
> void do_stuff(char*
2008 Jul 17
4
[LLVMdev] Casting between address spaces and address space semantics
In ISO/IEC WG14 n1169 on the C extensions to support embedded
processors, any two address spaces must be disjoint, must be
equivalent, or must be nested. As Eli indicated, the actual
relationship is platform specific depending on what makes the most
sense for your hardware and how the program will behave will depend on
that relationship.
-- Mon Ping
On Jul 17, 2008, at 7:25 AM, Eli
2008 Aug 11
2
[LLVMdev] Casting between address spaces and address space semantics
Hi Mon Ping,
> I don't have a problem having another class, TargetAddrSpace, to store this
> information. However, I don't think it make sense being a standalone pass.
> Address spaces seems to part of the TargetData and it seems more natural
> to ask the TargetData to return the TargetAddrSpace object (similar to
> struct layout) to describe the relationships
2008 Jul 22
2
[LLVMdev] Casting between address spaces and address space semantics
Hi Gordon,
> TargetData is a concrete class, part of the middle-end. It describes
> parts of the the target's ABI. It allows target-independent passes to
> do things like decide whether x[1] and ((char *) x)[4] alias. This is
> possible without actually linking with the code generator for the
> relevant target. TargetData can be encoded in the LLVM IR, e.g. target
2008 Aug 12
0
[LLVMdev] Casting between address spaces and address space semantics
Hi Matthijs,
On Aug 11, 2008, at 4:09 AM, Matthijs Kooijman wrote:
>
>> I don't have a problem having another class, TargetAddrSpace, to
>> store this
>> information. However, I don't think it make sense being a
>> standalone pass.
>> Address spaces seems to part of the TargetData and it seems more
>> natural
>> to ask the TargetData to
2008 Sep 15
1
[LLVMdev] Casting between address spaces and address space semantics
Hi Mon Ping,
> If I remember correctly, I was also not fond of passing another
> TargetAddrSpace reference to the TargetData object. I was hoping that we
> could encode the information as a target description string like we do for
> ABI information. I just don't want to end up with too many objects that
> describe the machine. One can argue that we shouldn't pollute
2008 Aug 07
2
[LLVMdev] Casting between address spaces and address space semantics
Hi Mon Ping,
I've again attached a patch, wich lets LLVM know about about the relations
between different address spaces. Instead of cramming this info in with
TargetData (with all kinds of unwanted side effects, especially for the IR), I
opted to create a new pass, TargetAddrspaces, which holds this information.
Just like TargetData, this can be added to the passmanager by the tool running
2008 Jul 22
0
[LLVMdev] Casting between address spaces and address space semantics
On Jul 21, 2008, at 11:58 PM, Matthijs Kooijman wrote:
>>
>> You probably want to somehow extend TargetData to encode the address
>> space descriptions, including pointer sizes and address space
>> relationships.
> Hmm, you have an excellent point there, pointer sizes could indeed
> easily have
> different sizes in different address spaces... That would make
2008 Aug 10
0
[LLVMdev] Casting between address spaces and address space semantics
Hi Matthijs,
Sorry for not responding earlier. I have a few comments.
On Aug 7, 2008, at 7:41 AM, Matthijs Kooijman wrote:
> Hi Mon Ping,
>
> I've again attached a patch, wich lets LLVM know about about the
> relations
> between different address spaces. Instead of cramming this info in
> with
> TargetData (with all kinds of unwanted side effects, especially for
2008 Jul 18
0
[LLVMdev] Casting between address spaces and address space semantics
Hi Eli, Mon Ping,
> In ISO/IEC WG14 n1169 on the C extensions to support embedded
> processors, any two address spaces must be disjoint, must be
> equivalent, or must be nested.
Ah, that standard is a lot clearer on this subject than the DSP-C one I read
was.
> As Eli indicated, the actual relationship is platform specific depending on
> what makes the most sense for
2008 Jul 21
0
[LLVMdev] Casting between address spaces and address space semantics
On 2008-07-21, at 14:42, Matthijs Kooijman wrote:
> Hi Mon Ping,
>
>> As you also mentioned, I don't like that we pass a reference to
>> TargetData with the AddrspacesDescriptor and that we have a static
>> default implementation store in the class. It is unclear to me if
>> this is the right class for it as not as it describes the structure
>> and
2008 Jul 21
3
[LLVMdev] Casting between address spaces and address space semantics
Hi Mon Ping,
> As you also mentioned, I don't like that we pass a reference to
> TargetData with the AddrspacesDescriptor and that we have a static
> default implementation store in the class. It is unclear to me if
> this is the right class for it as not as it describes the structure
> and alignment while address spaces seems distinct from that. I feel
> that
2008 Jul 22
3
[LLVMdev] Casting between address spaces and address space semantics
Hi Chris,
> >> You probably want to somehow extend TargetData to encode the address
> >> space descriptions, including pointer sizes and address space
> >> relationships.
> > Hmm, you have an excellent point there, pointer sizes could indeed easily
> > have different sizes in different address spaces... That would make
> > TargetData indeed a logical
2008 Jul 21
2
[LLVMdev] Casting between address spaces and address space semantics
Hi all,
> If I read the standard correctly, the properties of these address spaces can
> be fully captured by defining the relationship between every pair of address
> spaces (disjoint, identical, subset/superset).
>
> I think it would make sense to make these relationships backend/platform
> specific, but for clang and the optimization passes to properly work with
> address
2008 Jul 22
0
[LLVMdev] Casting between address spaces and address space semantics
On Jul 22, 2008, at 1:36 AM, Matthijs Kooijman wrote:
>> Yep, I think it makes sense for TargetData to have info about the
>> size/
>> alignment of a pointer in each addr space. That is also easy to
>> encode.
> Which is an added bonus, but the original subject under discussion
> was the
> relations between each address space (equivalent, disjoint, subset/
2011 Nov 21
0
In-place modification of a matrix
Hello,
Using the technique suggested here (
https://stat.ethz.ch/pipermail/r-devel/2007-September/047028.html),
we can update a matrix in place (see example 1 below), with huge time and
memory savings.
Is it possible to tweak example 2 to update in place also? The only
difference is that the matrix is held within a new environment.
Thanks,
Simon
# example 1 - fast and doesn't
2008 Jul 21
0
[LLVMdev] Casting between address spaces and address space semantics
Hi Matthijs,
Thanks for giving some code so we can discuss this in more concrete
detail. In terms of the information we need, I think you have it
right. We just need a description of how the different address spaces
relate and I don't see much of an issue with how you implemented to
InstructionCombining.
As you also mentioned, I don't like that we pass a reference to
2008 Jun 05
4
[LLVMdev] Adding DenseMap::FindAndConstruct with a default value
Hi All,
I've been fiddling around with a DenseMap to store cached copies of some
result. In short, I'm doing the following:
It = Map.find(Key)
if (It != Map.end() && It->second != Unknown)
Return It->second;
// do_stuff
return Map[Key] = Result;
However, I this requires two lookups in the hash table, which is not so nice.
Currently, there is no way to write this down so
2007 Dec 02
2
Optimised qmf_synth and iir_mem16
Hi all,
I've taken preglows ARM versions of qmf_synth and iir_mem16 from
rockboxes speex codec, and tweaked them a bit further for some more
speed.
I attach them here so you can review and take on any changes you
want.
Please let me know if you have questions etc.
Thanks,
Robin
--
Robin Watts, Email: <mailto:Robin.Watts@wss.co.uk>
Warm Silence Software, WWW:
2008 Aug 07
0
[LLVMdev] Casting between address spaces and address space semantics
Hi Matthijs,
>
>>> Specifically, I would like instcombining to be able to use this
>>> info to
>>> remove useless bitcasts. Also, this information is useful for
>>> clang to
>>> know when inserting an implicit cast makes sense and when it
>>> would be an
>>> error.
>> Clang should just reject implicit casts in *any*