On Tue, 5 Sep 2017, Richard Biener wrote:
> don't have any BITS_PER_UNIT != 8 port (we had c4x). I'm not
> sure what constraints we have on CHAR_TYPE_SIZE vs. BITS_PER_UNIT,
> or for what port it would make sense to have differing values.
BITS_PER_UNIT = size of QImode = unit that target hardwar
On Mon, 4 Sep 2017, Joseph Myers wrote:
> On Mon, 4 Sep 2017, Richard Biener wrote:
>
> > always have a consistend "character" size and how the individual
> > "characters" are encoded. The patch assumes that the array element
> > type of the STRING_CST can be used to get access to individual
> >
On Mon, 4 Sep 2017, Richard Biener wrote:
> always have a consistend "character" size and how the individual
> "characters" are encoded. The patch assumes that the array element
> type of the STRING_CST can be used to get access to individual
> characters by means of the element type size and tho
The following patch cures the missed optimization in PR82084, vectorizing
a wide-char initializer
wchar_t strs[4][2]= { L"A", L"B", L"C" , L"D"};
with AVX to
MEM[(wchar_t[2] *)&strs] = { 65, 66, 67, 68 };
it's not entirely clear to me whether the individual STRING_CSTs we
build for the gi
